On Tue, Jun 29, 2010 at 08:31:25PM -0400, Michael Gilbert wrote: > 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.
- Problems for all rdeps of xulrunner-1.9.1 and libmozjs2d, and all build-rdeps of libmozjs-dev and xulrunner-dev that don't depend on either of both (e.g. plugins), and ensuing problem for users of those packages. > 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. That surely can be arranged with a special security upload of the package displaying a message to the user in some way (which, IMHO, should be done with any package which security support is dropped) > - this will be a lot more work for the maintainers due to manual > backports of mozilla patches and? > - three different code bases to support: stable, testing/unstable, and > oldstable (when that is supported) and? > Anyway, I hope I've done a better job of clearly defining the scope of > the problem. I look forward to some constructive debate. Your debate is pointless. Why do you care ? What is your agenda ? Do you want me to list the same kind of problems webkit gives ? IMHO, webkit gives more headaches than mozilla. Simply because despite all you can say, you have several codebases for each debian suite. Each of which may or may not have some of the security issues. This is in no way any better than with mozilla. As for access to the security bugs information, relying on the public information is not enough anyway if you want to provide *timely* security updates. The current webkit support in debian is waaaaay after the facts. The current mozilla support in debian is only a few days off, merely because the CVE and MFSA information is not available to me until upstream releases its security update. Also, speaking of upstream security support, I have yet to see an upstream "stable" release of webkit that includes security fixes. I don't remember there was any for the GTK port, despite a promise for some, and I don't think there was any for the QT port either. At least, Mozilla continues to support older releases for some months after a new major release. So far, that doesn't appear to have been true for webkit. Actually, apart from Chromium, I don't think there are releases with security fixes in webkit at all. And even then, I don't think Chromium upstream releases security fixes for older major releases. The best you can do is actually to go through the CVEs and webkit security bugs, and find the relevant patches in svn, hoping they are not dependent on changes in the codebase between the moment it was fixed in svn, and the codebase you're trying to patch. And then, you have to account for the fact that you have several codebases in each debian suite. How exactly is that supposed to be better ? So, why exactly would we have to chose webkit over mozilla ? Because it's the new cool kid on the block ? Finally, the security team hasn't been involved in patching mozilla for years. AFAIK, patching is what makes most of the work in security support. Except this work is done by the mozilla maintainers and has been for a while. What exactly are you trying to get off the security team shoulders ? Handling a security build and issuing a DSA ? Following the advisories for mozilla ? All in all, will you just do something really constructive and stop this crusade of yours ? 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/20100630070836.ga3...@glandium.org
