Hi, On 05/28/2013 22:33, Moritz Muehlenhoff wrote: > As such, we'll switch to releasing the ESR releases of iceweasel > and icedove in stable-security. > Reverse-deps of the older xulrunner libs have negligable security > impact and we won't update them any further. > > One problematic aspect are the various xul-ext-* packages currently > packaged. It's very likely that some of them will break with ESR17 > and ESR24 in the future. > > However, there's not much we can do here. We can select a narrow (!) > set of important addons (e.g. enigmail for Icedove) that we will > keep in sync through stable-security, but that doesn't scale for > the full scale of Mozilla extensions currently packaged. > > In the future the majority of packages should thus rather be installed > through http://addons.mozilla.org instead of Debian packages.
As mentioned on IRC, I wonder what we should do with these extentions now and for future releases. There seem to be several options: a) Remove most Mozilla extensions from stable/testing/unstable and let users install them from addons.mozilla.org. Important addons could stay if agreed with release and/or security teams, e.g. enigmail (mentioned above) or adblock (part of the default Debian GNOME installation). b) Let maintainers update extensions via either -security or -(proposed-)updates. This causes additional work for the security team or the release team for at least coordinating updates. I wouldn't expect them to be able to review the changes which means a break from our current stable policy. b2) like b), but only do so for jessie and remove the extensions from testing/unstable. c) Let maintainers provide updated extensions via an additional repository (e.g. mozilla.d.n or some developer repository). I would expect some more packages giving us similar problems in the future: other web browsers (chromium) or web applications (owncloud?) where we might have to provide new upstream versions that require updating related packages (or breaking them). With my user hat on, I would like to have (b) though I'm not sure how much work it would be. I don't like (c). It's too similar to (b) with a workflow easy enough for the release/security team. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5ff74.6060...@debian.org
