On Tue, 29 Jun 2010 17:07:27 -0400 Michael Gilbert wrote: > Hopefully restating clearly this time: my proposal is to no longer > distribute mozilla packages in the main stable repository; instead they > can be maintained in backports (or volatile) at the choosing of the > maintainers of those packages (or converted to webkit to remain in > stable main). I propose no changes to the mozilla packages in unstable > or experimental.
I'm going to make one more attempt at assembling a sound argument supporting this proposal. Note that my only vested interest in the outcome of any decision is reducing the burden on the security team. I understand that Mike Hommey is ultimately responsible for any decision that may be made, and the consequences of that decision primarily only affect the mozilla maintainers' future workload (with some fallout on the security team). In the following lists, I break down the advantages and disadvantages of each approach. If there are other thoughts, I would be happy to see them included. Advantages of switching to backports: - very simple for the maintainers to keep up to date with respect to security updates (a matter of just recompiling the unstable/testing package for stable) - one (or almost the same) code base across backports and testing/unstable (and potentially oldstable-backports). Disadvantages of switching to backports: - no official security support. - potential confusing for users since the mozilla packages will not be available in a default install. Advantages of maintaining the status quo: - continue to provide a highly demanded packages where users expect to find it. Disadvantages of maintaining the status quo: - part way through the release, security support will end and many users won't even notice (unless they're subscribed to debian-security); leaving a lot of the Debian user base vulnerable. - this will be a lot more work for the maintainers due to manual backports of mozilla patches - three different code bases to support: stable, testing/unstable, and oldstable (when that is supported) Anyway, I hope I've done a better job of clearly defining the scope of the problem. I look forward to some constructive debate. Best wishes, Mike -- 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/20100629203125.af7af9af.michael.s.gilb...@gmail.com
