Websites/Plugincheck: Difference between revisions
Espressive (talk | contribs) No edit summary |
Espressive (talk | contribs) mNo edit summary |
||
| Line 48: | Line 48: | ||
[https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites All bugs against plugin-check] | [https://bugzilla.mozilla.org/buglist.cgi?list_id=9821011&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=plugins.mozilla.org&product=Websites 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: | 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: | ||
Revision as of 13:40, 7 May 2014
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
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.