LWN: Comments on "Beyond Firefox 4.0: Handling an accelerated development cycle"

Beyond Firefox 4.0: Handling an accelerated development cycle

dlang — Mon, 21 Mar 2011 05:03:58 +0000

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.

Beyond Firefox 4.0: Handling an accelerated development cycle

vonbrand — Mon, 14 Mar 2011 14:02:23 +0000

less-418 was released on January 8, 2008.

Beyond Firefox 4.0: Handling an accelerated development cycle

nix — Mon, 14 Mar 2011 13:49:11 +0000

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

jezuch — Mon, 14 Mar 2011 10:00:21 +0000

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

eduard.munteanu — Sat, 12 Mar 2011 13:38:14 +0000

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

anselm — Fri, 11 Mar 2011 22:15:34 +0000

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

christoph_d — Fri, 11 Mar 2011 18:53:46 +0000

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

sorpigal — Fri, 11 Mar 2011 15:34:24 +0000

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

sorpigal — Fri, 11 Mar 2011 15:30:34 +0000

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

jrn — Fri, 11 Mar 2011 01:36:14 +0000

> 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

nicooo — Fri, 11 Mar 2011 01:18:18 +0000

> Does this help you see what the problem is?

Yeah, xulrunner.

Beyond Firefox 4.0: Handling an accelerated development cycle

elanthis — Thu, 10 Mar 2011 22:26:22 +0000

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

vonbrand — Thu, 10 Mar 2011 17:28:07 +0000

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

vonbrand — Thu, 10 Mar 2011 17:25:17 +0000

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

patrick_g — Thu, 10 Mar 2011 16:30:00 +0000

>>> especially since Mozilla only offers 32-bit packages as the official build for Linux users

Really ? 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

jzb — Thu, 10 Mar 2011 15:02:35 +0000

"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

bryanlarsen — Thu, 10 Mar 2011 14:14:29 +0000

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

kragilkragil — Thu, 10 Mar 2011 10:41:09 +0000

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

AndreE — Thu, 10 Mar 2011 08:45:23 +0000

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

epa — Thu, 10 Mar 2011 08:36:53 +0000

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

viiru — Thu, 10 Mar 2011 08:14:23 +0000

> 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

rhertzog — Thu, 10 Mar 2011 08:12:59 +0000

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

AndreE — Thu, 10 Mar 2011 06:00:34 +0000

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

dberkholz — Thu, 10 Mar 2011 03:50:59 +0000

As does Gentoo.

Beyond Firefox 4.0: Handling an accelerated development cycle

Sufrostico — Thu, 10 Mar 2011 03:36:49 +0000

To me this is just a marketing strategy.

- Google Chrome is version 10
- Mozilla Firefox is version 3.6

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

joey — Thu, 10 Mar 2011 02:53:06 +0000

Debian stable includes chromium-browser too.

Beyond Firefox 4.0: Handling an accelerated development cycle

idupree — Thu, 10 Mar 2011 01:41:38 +0000

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

jetm — Thu, 10 Mar 2011 01:26:03 +0000

That won't be problem for a rolling release distribution like ArchLinux, Gentoo and LMDE.