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

Infrastructure

ToDo

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.

Plugin Data as an Open Service

Seeing that there is no inherent private data in the information on plugin release statuses, another idea that was discussed, was to borrow from the process followed to manage information about browser feature support at caniuse.com [1]. The basic process is as follows:

1. JSON files for each plugin are stored at: https://github.com/ossreleasefeed/plugin-status-service/tree/master/data
2. From here, vendors, community members, pretty anyone comfortable with Git/Github/JSON can fork the repo
3. Once there is a new release, a user can simply open up the JSON file for the affected plugin and update or add the details of the release.
4. Once the information has been updated, the user pushes the change to their repo and opens a pull request against the main repo.
5. Trusted users who have been given merge access to the main project repo can then review the PR and merge
6. Once a merge to master has been made, a service such as leeroy can be used to kick off a process that would pull down the latest from Github and then call the following file via Node: https://github.com/ossreleasefeed/plugin-status-service/blob/master/db/create_plugincheck.js
7. Once that process is complete, a new mongodb instance of the DB will exist and subsequent calls to the service will respond with up to date information.

This project has largely been abandoned as the use of Git/Github/JSON is too prohibitive, and perhaps adds to much complexity.