Websites/Plugincheck

This page contains all of the important details for the PluginCheck websites.

Overview

• Project name: PluginCheck

Environments

Front End

• Prod URL: http://www.mozilla.org/plugincheck
• Stage URL: http://www.allizom.org/plugincheck

Back End

• Prod URL: http://plugins.mozilla.org
• Stage URL: http://plugins.allizom.org

Code Repositories

• Back-end Repo: https://github.com/mozilla/plugindir/
• 'Middleware' Repo: https://github.com/ossreleasefeed/Perfidies-of-the-Web
• Front-End Repo: https://github.com/mozilla/bedrock
• Experimental Repos: https://github.com/ossreleasefeed/plugin-status-service, https://github.com/ossreleasefeed/plugincheck

Communication

• IRC Channel: #plugincheck on irc.mozilla.org

Team

The primary and secondary contacts for each role of this project:

• Product owner - Kev Needham
• Web Project Manager - Laura Thomson
• Developers - Schalk Neethling, Carsten Book, Peter Bengtsson
• Designer - John Slater
• QA - Matt Brandt
• UX - John Slater

Current Trackers

• Tracker for The New PluginCheck for Firefox 29+
• Tracker for Bugs and Feature Requests PluginCheck.current
• Test Automation for PluginCheck

Bugs Needing Triage

All bugs against plugin-check

Ideas On Improving PluginCheck

Plugin Release Notifications by Vendors and Community

One of the problems we have with plugin check is that currently, there is no easy, consistent way for plugin vendors, community members and generally users everywhere to notify us of new releases of plugins. Whether those be *new* release, security releases or whatever the case may be. One option to solve this problem is as follows:

1) Create a simple form, that defines the fields of data we need for a plugin release notification and then expose this form to the public.

NOTE: Of course, it cannot be completely 'open' and we should have an authentication mechanism. The one that immediately comes to mind is BrowserID but, there will need to input here from outside parties to determine whether this is the most secure solution. One thing to note, is that LDAP is not an option, as we want not only vendors but also community members to make use of this service.

2) When a user submits the form, we use the Bugzilla API to create a new bug, against a specific product, for the notification. 3) When the bug is created, the list of people who can update the plugins DB, as well as the QA person, is automatically CC'd via email. 4) Over time, as more users reach a certain trust level, we can add more people to the CC list who can then act on those bugs.

Plugin Announcements via Email

Another idea that was discussed was plugin release notifications via email.

1) Emails would be sent, in a specified format, from the vendors directly to a dedicated email address. 2) From there a cron would process the mailbox ever say 8 hours 3) If new mail exists, it would be picked up and the data in the mail would be transformed into a format that is required for the DB. 4) This data would be inserted into a kind of sandboxed table 5) There would then be a simple Django based admin interface, behind LDAP, that a user can log-in and approve these sandboxed announcements 6) At this point it would be moved to the live plugins database.

With the above there was security concerns raised around the email portion of this solution and, I believe, after some discussion, this has largely been abandoned.