[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xulrunner 1.9.2 into sid?

On Mon, 28 Jun 2010 13:54:28 +0200 Mike Hommey wrote:

> On Mon, Jun 28, 2010 at 05:36:11AM -0600, Aaron Toponce wrote:
> > Ah yes, Iceape. Their releases are so few and far between, this could
> > possibly mean that we won't see Iceweasel 3.6 or Icedove 3.1 for some
> > time, correct? Upstream Seamonkey 2.1 will be build against gecko 1.9.3,
> > but its release date is TBD. Upstream Firefox 4 is due the end of the
> > year, based on 1.9.3, and will likely be ahead of Seamonkey. So where
> > does that put us? Seems trying to keep the two projects aligned is some
> > task. :)
> (note 1.9.3 is apparently going to be reversioned to 2.0)
> > Will Iceweasel 4 go into Sid when Iceape 2.1 goes into Sid?
> 3.6 will go into sid when squeeze is released. It will remain in
> experimental until then, except if the plans change.
> 4.0 betas will go into experimental then. In the meanwhile, they will
> probably be provided somewhere on mozilla.debian.net.
> 4.0 will go into sid when it is released.
> > > First, TB 3.1 has just been released, and as such hasn't been widely
> > > tested in Debian. It usually isn't very wise, that close to the expected
> > > freeze time, to upload a new major release of a not exactly small and
> > > trivial software.
> > 
> > I can understand this, but I would imagine the release of Squeeze is at
> > least 8-10 months out. We still have a good deal of RC bugs to get
> > through. Of course, packages this size will add to the count.
> Supposedly, the freeze is somewhen in august. After that, getting a new
> major version in the archive is a no-go.
> > > Second, for the reasons given earlier, releasing with iceweasel 3.6 and
> > > icedove 3.1 would mean to avoid releasing with iceape 2.0. This may not
> > > be a huge problem, as we already didn't release lenny with iceape, but
> > > see below.
> > 
> > Iceape is a beautiful piece of software, and I have run it in the past.
> > But market share shows that Seamonkey/Iceape users are the minority,
> > with Firefox/Iceweasel and Thunderbird/Icedove the vast majority.
> > Releasing Lenny without Iceape was the best move, IMO.
> If Debian accounted for market share, it would dump a whole lot of
> packages. There are a lot of packages with less users than iceape.
> > > All in all, I still think releasing squeeze with iceape 2.0, iceweasel
> > > 3.5 and icedove 3.0 is the best course of action.
> > 
> > Is this really the best move? With Firefox 4 due the end of the year,
> > and 3.6 will be a year old already, the security team will be supporting
> > 3.5 after Mozilla stops it's support. Same might be the case with
> > Icedove 3.0.
> Choosing between 3.5 and 3.6 on that alone is not enough.
> As I said, Mozilla will also stop supporting 3.6 way before squeeze
> security support ends.

This discussion brings up an opportunity to debate the merrit of
continuing to suffer the chilling effects of a self-interested upstream
(i.e. mozilla no longer attempts to play well in the open source
ecosystem since it has no impact on 90% of their marketshare). Based on
their latest decision to go to a 6-month only support cycle, it will be
impossible to support their package for the 3+ year lifetime of a
stable release (especially since since they purposely leave out patch
information in their advisories, which is needed to independently solve
their problems). In fact, at the current rate, 3.5 will be end-of-lifed
before squeeze gets out the door. Chilling affects have already been
felt: etch had to drop support for iceweasel 6 months before its
end-of-life as well. Also since 3.0 is already end-of-lifed, support
for iceweasel in lenny will need to end soon (a year or more before the
end of that release).

There are a couple solutions to this problem.  In light of the new
upstream support timeframe, Ubuntu has decided to sacrifice stability
(opting to push new major upstream releases into their stable versions)
and engage in poor supportability/secuirity practices (using embedded
code copies instead of system libraries) [0]. This path is
unnacceptable for Debian.

In my personal opinion, the only viable option left is to drop all
mozilla and mozilla-depending packages from main, and provide them in
backports (as suggested already in another message in this thread).
Backports' rolling release model makes it the perfect avenue to adhere
to mozilla's dictated treadmill.  It may take quite a bit of work to
excise the offending packages, but there is still quite a bit of time
before the squeeze freeze; so it should be doable.  With respect to 
upgrades from lenny, perhaps the iceweasel packages could upgrade to
epiphany or chromium and provide a message about using backports
informing the user about how to continue using iceweasel if that's
really what they want.

Losing mozilla wouldn't be that significant of an loss since there
are plenty of other good options nowadays (webkit, konquerer, chromium,
etc.), which wasn't the case a year or so ago.  Although webkit does
have a few supportability problems of its own, they are more tractable
than mozilla issues. The first problem is that there are *a lot* of
security issues, which may just be a "growing pain". In fact, I spent
about 5 hours today triaging about 40 webkit security issues, and
patching 20 of them. However, in spite of this daunting task, it was
relatively straightforward since the svn commits were obvious in most
of the announcements.  Restating this, webkit plays better in the open
source ecosystem.  Mozilla actively makes it hard to stay up to date
(by providing as little information as possible in their advisories);
webkit (for the most part except for Apple announcements) makes it
easy.  This means security fixes are going to happen a lot faster since
there is a lot less downtime waiting for patches to by disclosed.
Another webkit downside is that all updates need to be re-applied
separately to about six different forks (konqueror, chromium,
webkit-gtk, kdelibs, kde4libs, qt4-x11), but once the work is done for
one, its relatively straightforward to check and copy the needed
patches.  I think that a unified webkit library that doesn't need to be
forked should be a release goal for squeeze+1 to address this
particular problem. 

Anyway, I don't want to diminish all of the work that Mike Hommey has
put into the mozilla packages over the years, which is immensely
significant, but there comes a time where the negatives far outweigh
the benefits.  I think we reached the tipping point a couple years ago,
and it's time to do something about it now.

Best wishes,


Reply to: