To confirm, yes we have a list of all the add-ons that are bootstrapped. To get access to that special ability the teams agree that testing and maintenance is their responsibility. I agree that removing legacy XPCOM functionality is the priority and the focus should be keeping tree herder green.
There needs to be an exit strategy for these add-ons from the current siutation, but as you can see there's more to this about how these things are developed. The fact that teams are opting choose to use different tools again brings up the same conversation that devtools had. At this point, now we are post 57, we are starting to work with those teams to find a solution. On 15 November 2017 at 08:31, Kris Maglione <kmagli...@mozilla.com> wrote: > On Wed, Nov 15, 2017 at 04:12:06PM +0200, Henri Sivonen wrote: >> >> On Wed, Nov 15, 2017 at 3:16 PM, Andrea Marchesini >>> >>> This is why we had this issue. It should not be impossible for a >>> 'standard' >>> webextension to generate such mess. >> >> >> How many Mozilla-signed special extensions are there? Does an analog >> of https://dxr.mozilla.org/addons/ exist for searching their code? Is >> there a CI system testing that the continue to work? > > > The situation is pretty bad at this point. Ideally, all XPCOM add-ons that > we support should run tests in treeherder on checkin, both for add-on > changes and m-c changes. But as of now, most system add-ons, Test Pilot > add-ons, and SHIELD studies are hosted on Github and do their own ad-hoc > testing, mostly using Node-ish testing frameworks. > > There's also no standard place to host or index all of this add-on code, or > even to get a list of what such add-ons exist. At one point, I asked for all > SHIELD add-ons to at least be hosted in the same Github organization. The > same should probably go for all other Mozilla-signed add-ons. That would at > least give us a single place to find any XPCOM add-on code that we still > support. > > In the mean time, though, as far as I'm concerned, the maintainers of those > add-ons are responsible for dealing with breakage that results from not > having in-tree tests and a standard place to search that code. If you're > removing legacy XPCOM functionality, all you should need to care about is > whether treeherder is green. > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
