Weekly Edition
Return to the Distributions page
| |||||||||||||
Beyond Firefox 4.0: Handling an accelerated development cycleFirefox 4.0 has been delayed a number of times, but looks to finally be on the verge of release. With 4.0 out the door, the Mozilla developers will be pursuing a quarterly release cycle that would see Firefox 5, 6, and 7 released by the end of 2011. For Windows and Mac users, accelerated releases just mean they'll see more frequent updates. For Linux users, and for distribution vendors, quarterly releases may pose a few challenges. Many have complained that the six-month release cycle followed by Ubuntu and Fedora is too brisk, but the proposed Firefox release plan will be even more aggressive — averaging a major release each quarter. This means that it's likely that Mozilla will release two major Firefox updates during a distribution development cycle. To be sure, the releases will not be as significant as the Firefox 4.0 update. Mozilla plans to shift the way that it approaches major releases so that there will be fewer features per release, but continual improvements. This is fine for users who get their updates directly from Mozilla, but it looks likely to pose a challenge for Linux distributions and users who want to run current Firefox releases as part of the distribution. Most distributions have a policy of providing only security updates for packages after the distribution has shipped. Firefox has already been an outlier in this regard. For desktop Linux releases, Firefox is a key component — and Linux desktop users typically don't want to run an aging or obsolete browser. Firefox's major releases often don't fit well with Linux distribution release cycles — particularly since Mozilla has been known to slip release dates by rather a lot. Firefox 4.0 is a prime example of this, having originally been scheduled for an October release. In consideration for users, distributions have made special exemptions to update policies by working with Firefox betas during the development cycle and then shipping updates to bring Firefox up to the final release. How will they handle major bumps to Firefox that happen at a much faster pace? Right now, users on released versions of openSUSE, Ubuntu, and Fedora have the option of installing major Firefox updates from add-on repositories. The openSUSE Project has its Mozilla repository, which allows users to track major updates for stable openSUSE releases. (This should also be suitable for users of SUSE Linux Enterprise Desktop.) Users can also track openSUSE Tumbleweed and receive the stable updates for pretty much all of the major packages, if they're so inclined. Ubuntu currently offers a PPA for new versions of Firefox, and Fedora has the "Remi" repository. These solutions are fine for users who are familiar with advanced package management. (LWN readers may not consider adding a PPA or RPM repository "advanced," but many users would.) But all of these require users to seek out and add package repositories, which may have been OK when Firefox major releases were spread out by more than a year — but not so much when they become a quarterly affair. How will the major distributions handle this? Fedora is unlikely to issue major Firefox updates after release, at least for the time being, through the regular update channel. Fedora's Christopher Aillon, who is responsible for the official Firefox packages, says that this is due to the number of packages that depend on the Firefox platform (XULRunner). He adds that "speeding things up won't help that," but that the situation may change as more packages depend on Webkit instead of Firefox/XULRunner "but it's not on the immediate radar." What about security fixes? Aillon says that it might involve more backporting of security patches, but "it will be nothing new to us. We know the codebase very well and I'm confident that Fedora's packages will remain stable and secure." As for openSUSE and future stable releases, it's not decided yet how the project will handle Firefox updates. openSUSE's Wolfgang Rosenauer says that "I haven't discussed these plans deeply yet since I was busy wrapping up Firefox 4 for 11.4. Actually I guess the whole Mozilla project was [wrapping up Firefox 4.0] and most of the planning and discussion will take place from now on." According to Canonical's Jason Warner, users can continue using the PPA to grab major updates of Firefox. As long as the version of Firefox shipped with an Ubuntu release is receiving security fixes, Ubuntu will stay with that release. However, Warner says that Ubuntu will ship major releases of Firefox as an update if Mozilla stops supporting the earlier release. For example, "We will continue updating FF 3.6 for 10.04 users as long as Mozilla supports that release (typically 6 months after a major release). Once Mozilla stops supporting 3.6 we will update to the latest stable release, whichever number that is at the time." It looks like Red Hat will make newer releases of Firefox available for desktop/workstation users of Red Hat Enterprise Linux (RHEL). Actually, the company has been handling updated releases of Firefox for some time in its older versions. I pinged Red Hat PR and they responded that Firefox 3.6.x is already being shipped for RHEL 4, 5, and 6. According to Red Hat the plan is to "stay as close as possible to the latest Mozilla release, while at the same time ensuring we provide customers with a stable and secure web browser." This is largely uncharted territory for distributions and Mozilla. Google's Chrome browser and Chromium project have been doing rapid-fire releases for some time, but have largely bypassed the distributions. Google provides its own packages for Linux users, and only Ubuntu packages Chromium in the default repositories. It would be nice if Mozilla provided native packages for Linux users as well, especially since Mozilla only offers 32-bit packages as the official build for Linux users. If Mozilla manages to keep to its schedule for 2011 it will be interesting to see how it shakes out for distributions and how they deal with the new development cycle. It will likely require creating some exceptions to policies on shipping major updates rather than just security releases, or perhaps rethinking how releases are handled in general. (Log in to post comments)
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 1:26 UTC (Thu) by jetm (guest, #61129) [Link]
That won't be problem for a rolling release distribution like ArchLinux, Gentoo and LMDE.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 17:25 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Just that they will have to roll over lots of other packages in sync. That is the problem, not the updating of a single package (or a few related ones).
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 1:41 UTC (Thu) by idupree (subscriber, #71169) [Link]
Arch Linux has Chromium in its default repo ("[extra]", the same repo that has X, Firefox, most GNOME and KDE software, etc.). Of course, we are a cutting-edge rolling-release distro. So old-version-support problems don't arise very much. (Arch, unlike Gentoo, doesn't even slightly try to support old versions once we've packaged the latest one.)
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 2:53 UTC (Thu) by joey (subscriber, #328) [Link]
Debian stable includes chromium-browser too.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 3:50 UTC (Thu) by dberkholz (subscriber, #23346) [Link]
As does Gentoo.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 3:36 UTC (Thu) by Sufrostico (guest, #68053) [Link]
To me this is just a marketing strategy.
- Google Chrome is version 10
They want to reach the same numbers of Google Chrome. To Developers is non-sense but for most windows end users, numbers (not even features) matters.
Kind off the same thing that Slackware did years ago (Jump some version numbers just for marketing).
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 14:14 UTC (Thu) by bryanlarsen (guest, #26230) [Link]
That doesn't seem to be the game that Google is playing. How many users actually know what version of Chrome they're running? It auto-updates in the background pretty much silently. Google probably wants to make it as much like gmail as possible -- do you know what version of gmail you're running?
It's also the same model the Linux kernel uses. Given that the 3rd number is the only significant one these days, we might as well call the latest linux kernel "38.rc8".
So no, I don't think it's marketing -- I think it's just good engineering. Using the Linux kernel as your model for release cycles is probably not a bad idea for most projects.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 15:02 UTC (Thu) by zonker (subscriber, #7867) [Link]
"To me this is just a marketing strategy."
It is not, at least not in the sense that you're suggesting. Firefox does not make an inordinate fuss over its version numbers - pretty much only to the extent required to encourage people to upgrade quickly. Google does not make much of a fuss about version numbers at all.
It is a strategy to compete with Google Chrome by rolling features out much more quickly. If you've lived with the stable Firefox release 3.6 through its lifecycle, rather than upgrading to the betas for 4.0, you've had the same feature set for close to a year. Chrome users, on the other hand, have continued to get new features on a regular basis.
Firefox is trying to change that and match Chrome's development style by pushing updates out more quickly.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 15:30 UTC (Fri) by sorpigal (subscriber, #36106) [Link] Then why not go with 4.1, 4.2 and 4.3 instead of 5, 6 and 7? If it doesn't matter and users don't care and it's not about marketing how about continuing a practice that makes sense and makes me happy?
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 22:15 UTC (Fri) by anselm (subscriber, #2796) [Link] I say they want to catch up with Internet Explorer, which is around version 9 these days.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 14, 2011 10:00 UTC (Mon) by jezuch (subscriber, #52988) [Link]
And end up like the Linux kernel, at (for example) 4.38, without a reason to bump the major number ever again? In the world of "cadence" and incremental updates the <major>.<minor>.<micro> versioning scheme is more and more obsolete.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 14, 2011 13:49 UTC (Mon) by nix (subscriber, #2304) [Link]
I'd call it less(1) and less(1) obsolete. (What's that at now? Version 441?)
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 14, 2011 14:02 UTC (Mon) by vonbrand (subscriber, #4458) [Link]
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 6:00 UTC (Thu) by AndreE (subscriber, #60148) [Link]
I've never understood why userland updates are so problematic. Adopting a system /world distinction like in FreeBSD would allow distros to maintain system stability while allowing users to run the most recent applications
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 8:14 UTC (Thu) by viiru (subscriber, #53129) [Link]
> I've never understood why userland updates are so problematic. Adopting a
> system /world distinction like in FreeBSD would allow distros to maintain > system stability while allowing users to run the most recent applications
It's not quite so simple. How does the distinction go with for example Firefox? It might seem to be an obvious case for "world" as it is a end user application. But is it? Let's take a quick look. On a Debian Squeeze system, there are 39 packages that depend on xulrunner (the rendering engine / user interface library of Firefox). You can't actually update Firefox without updating xulrunner, and if xulrunner is not fully backward compatible (it usually isn't), you may need to update the other 38 packages as well.
Some have claimed that Debian should ship an embedded copy of xulrunner with every depending package, but that just moves the problem to security updates (which are extremely frequent for our example case xulrunner), where instead of updating one package the security team needs to update all 39.
Does this help you see what the problem is?
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 8:36 UTC (Thu) by epa (subscriber, #39769) [Link] I don't understand why distros do not have a 'xulrunner-stable' which other apps depend on and which doesn't have to update whenever Firefox bumps its internal version of the XUL libraries. Since Mozilla (AFAIK) makes no commitment to provide a stable API for xulrunner, this seems a simple necessity.But then, of course, somebody would need to backport security fixes to the stable xulrunner, so it's not that simple.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 8:45 UTC (Thu) by AndreE (subscriber, #60148) [Link]
As mentioned above, splitting the packages could work. Also, this problem is not so bad with libraries that don't break compatability. Those that do could follow a -stable / -new naming scheme if needed. I'm running firefox 4 from a repo on F14 that pulled in its own xul-runner, along side the system provided firefox 3 and thunderbird, so it does work (need to check the naming scheme)
Ultimately, I think a more granular update policy makes a lot of sense, and not just in this case. There is no reason that the firefox, xul-runner, or Open Office versions need to be as stable as the kernel version, Xorg version, or DE version throughout the lifetime of a distro.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 1:18 UTC (Fri) by nicooo (guest, #69134) [Link]
> Does this help you see what the problem is?
Yeah, xulrunner.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 8:12 UTC (Thu) by rhertzog (subscriber, #4671) [Link]
For Debian users, there are APT repositories at http://mozilla.debian.net to get the latest versions. And as Joey pointed out, chromium-browser is in Debian stable.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 10:41 UTC (Thu) by kragilkragil (guest, #72832) [Link]
Mozilla needs to wise up. Google is very clever in that they provide repos for all major distros. Mozilla must do the same. Just remove the distro referals and that move pays for itself.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 17:28 UTC (Thu) by vonbrand (subscriber, #4458) [Link] And then Mozilla will have to take over maintenance of the 39 xulrunner-dependent packages in Debian, and in Fedora, and...
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 16:30 UTC (Thu) by patrick_g (subscriber, #44470) [Link] >>> especially since Mozilla only offers 32-bit packages as the official build for Linux usersReally ? There is a Mozilla.org FTP server with x86-64 builds : ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0rc1/linux-x86_64/ It's not official ?
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 10, 2011 22:26 UTC (Thu) by elanthis (guest, #6227) [Link]
And this is why the traditional distro package model is entirely broken by design. The application vendors should be responsible for packaging and distributing their applications. Preferably just once rather than 60 times for 60 different distributions.
Red hat, fedora, debian... None of them should be shipping 50,000 packages, as the vast vast majority of those should be upstreams responsibility.
Yes, distributions currently apply a lot of fixes to upstream. Because they have to because they taught upstream to be lazy idiots. If upstream were forced to actually take responsibility for their software, then the software worth using would shape up (If nothing else, the hordes of duplicate package maintainers for an app could just go work on upstreams repo/packages directly), and the poorly maintained apps will die off like they rightly deserve.
There is not one single _real_ technical dilemma with this. Just lots of whining and screaming and idiotic rambling by distro developers that care more about their control-complex than actual usability or user support. All of the barriers to having upstream package their software and distribute it (with full cross-vendor dependency resolution) are artificial barriers intentionally created and enforced by the distribution developers.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 1:36 UTC (Fri) by jrn (subscriber, #64214) [Link]
> Yes, distributions currently apply a lot of fixes to upstream. Because they have to because they taught upstream to be lazy idiots.
Do you remember what life was like before the major distributions? (I don't mean to point to any particular conclusion by this. You just might find it interesting to look into.)
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 15:34 UTC (Fri) by sorpigal (subscriber, #36106) [Link] I agree, so long as upstream vendors agree to stay in compliance with Debian policy. Third party apps that crap all over my filesystem and do things their own way when a policy exists tend to get uninstalled rapidly.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 11, 2011 18:53 UTC (Fri) by christoph_d (subscriber, #62481) [Link]
Then you have solved the problem on how to track fixes for all the software? I'm currently having >2k packages installed (and that's not much compared to some other of my systems) .. querying 2k websites/repositories for updates just doesn't scale up not even if it's automated in one single tool.
would be interesting how you are going to handle soname changes or want to ensure that applications are not using library versions where security support ended years ago
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 12, 2011 13:38 UTC (Sat) by eduard.munteanu (guest, #66641) [Link]
I really hope Firefox people will reconsider this proposed versioning system. It's seriously reducing information related to stability and major architectural changes. And for what? So that Firefox plays catch-up with other browsers? It certainly doesn't mean more work is being put into it and it certainly doesn't help setting realistic goals.
It's really good to see a move towards releasing more often, but messing up with the versioning scheme in this way is bad. Other projects are able to keep up with similar goals without resorting to such tricks. Just release when something gets done, not just because a few months have passed.
Maybe the problem lies in merging too much too soon? Maybe those features should stay out of the main tree until most issues/bugs have been ironed out? I don't know, I'm not involved in Firefox development, but perhaps there are better solutions to this problem.
Beyond Firefox 4.0: Handling an accelerated development cycle Posted Mar 21, 2011 5:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
what stability information do you think is being lost?
it sounds like you are under the impression that the developers introduce new stuff for a .0 release and then only fix bugs for .1, .2, etc.
the sad reality is that they are introducing new stuff for every release, so there are no releases that are as stable as you are thinking they are.
on the other hand, as the kernel development has shown, you can get good results both for stability and for rapid introduction of new features with a rapid release cycle.
but when you do this sort of rapid release cycle, you really don't have a reason to believe that any release is significantly better than any other (without testing). how good the releases are will depend a lot on the testing that gets done on the patches before they are put in upstream. it may be that there is reason for a series of bugfix-only branches (like the kernel -stable series), but we'll have to see at what rate new bugs are introduced, and who is willing to backport the bugs for how long.
|
|||||||||||||