We can easily make the containers addon a Web Extension and take out the bootstrap.js code. But until today (with 57 out the door), we couldn't do that. We could only host one version of the addon on AMO, so we had to host one that was compatible with release. Now that 57 is out the door, we can convert to a full web extension and release.
On Wed, Nov 15, 2017 at 11:22 AM, Robert Helmer <[email protected]> wrote: > On Wed, Nov 15, 2017 at 8:31 AM, Kris Maglione <[email protected]> > 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. > > > I followed up w/ jkt about the bug in question here, and the reason > for the backout is that the feature was broken on NIghtly for users > without the add-on. The add-on was *also* broken, but I agree with > everyone else in the thread so far that we should not be backing out > changes from mozilla-central because it breaks an add-on produced by > Mozilla. > > > >> 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. > > > We shouldn't try too hard to solve for our *current problem* though - > as we wind down bootstrapped add-ons and use webextensions for > everything Mozilla ships, folks that want to contribute Mozilla-only > webextension APIs will need to do so using whatever the standard > Firefox development workflow is. We're in a transition period now > though where webextensions can't do the sorts of things we use Test > Pilot and Shield Studies for, yet. > > All this doesn't matter to Firefox developers though. If you break > someone's bootstrapped add-on at this point and their CI doesn't catch > it, that's on the add-on author(s) to fix. > > > > 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. > > > Strongly agree here... I think an indexed archive of everything we've > shipped would be helpful. Personally I don't really care how people > developed the add-on (they can be emailing patches around a mailing > list for all it matters), but we should have a single place to see > what shipped and when. > > > > 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. > > > Yes. > > My understanding is that the change in question here was not backed > out due to the extension being broken, and that should continue to be > the case. I'd love to be corrected here if I have this wrong! > > > > > > _______________________________________________ > > dev-platform mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
