Re: xulrunner 1.9.2 into sid?
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
> 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
> - 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.
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
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 ?