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, Mike [0] https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel -- 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/20100629025732.ea397666.michael.s.gilb...@gmail.com
