On Wed, Nov 15, 2017 at 8:31 AM, 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.
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 > 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
