It's fine to keep it as-is for now, but I think the goal should be to get rid of it (and possibly Tech Evangelism :: Addons too) for the same reasons as Benjamin noted in his first email.
Seem like most of this component's original intent (naming aside) is covered by those new components. Compatibility issues with the WebExtensions APIs themselves would go in Toolkit::WebExtensions (or possibly a new :: WebExtensions:Compatibilty if someone feels the distinction is important). Otherwise I'd expect "issues in Firefox that affect extensions" to live in an appropriate component where the right people can see them. For example, if some bug in the JS engine broke Extension X, that should just be filed in Core :: JavaScript Engine. (And we already have an "addon-compat" keyword to flag/track such bugs globally.) Justin On Mon, May 2, 2016 at 3:59 PM, Andrew McKay <amc...@mozilla.com> wrote: > I agree, let's just leave its name as it is for now. > > On Mon, May 2, 2016 at 3:54 PM, Matthew N. > <mattn+firefox-...@mozilla.com> wrote: > > On Mon, May 2, 2016 at 3:43 PM, Emma Humphries <e...@mozilla.com> wrote: > >> > >> Andrew, can you do a pass over the bugs since Jan 1st and, and let's > >> rename this FFx::Add Ons Compatablity so that it's clear it's not > plugins. > > > > > > Extensions and plugins are both types of add-ons so renaming makes it > less > > clear as it then includes plugins and themes. > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
