Everyone reading this is probably already well aware of Mozilla’s (now not-so) new 6-week release cycle for Firefox, and that we (Ubuntu) have been delivering these new releases to Ubuntu users since 11.04. We’re going to continue to do this for the next LTS, Ubuntu 12.04, and with the big drive for increased quality for this cycle, we need to ensure that this quality is maintained for the 5 years that the LTS is supported. The Firefox release process obviously brings some additional challenges in this area that we don’t have for other applications in Ubuntu.
Stable release updates (SRUs)
Traditionally for other applications, all individual changes landing in to a stable release are reviewed for quality and suitability. All changes go through the “proposed” pocket where they can be tested by a limited audience for 7 days before being released to the general user base. All individual changes generally have a test case that users of the proposed pocket can follow. This process is documented here
It isn’t realistic for us to review every individual change in each new Firefox release, nor is it realistic for us to write a test case for each individual change and ask a small number of users to verify them. It is also not normally appropriate to delay security updates for 7 days whilst we wait for feedback from proposed testers. Because of this, we haven’t used the traditional SRU method to deliver Firefox updates in the past.
So, what’s the problem now?
With the new 6-week releases introducing more than just security and stability fixes, we need to rethink how we test browser updates. The SRU process doesn’t scale well to browser updates for a few reasons:
- We can’t wait 7 days after the official Mozilla release to ship a security update
- The SRU process is great for testing self-contained, specific and isolated fixes with a well defined test-case, but I would question the value of dropping a browser update in to the proposed pocket every 6 weeks, asking users to run it to “see if it works ok” and then waiting for one user to wave their hand on a bug report to say that they started it and it seems to run (eg, this comment on Firefox 5 tracking bug)
- A few days testing every 6 weeks isn’t long enough. In fact, 7 days is nowhere near long enough in my opinion.
Well, how do Mozilla handle this?
Each Firefox release has 6 weeks of development, followed by 12 weeks of stabilization whereby the release is tested by a community of enthusiastic testers. This process can be visualized by the following graphic, borrowed from here.
You can see that there are 4 channels running in parallel (these are called nightly, aurora, beta and release), and each Firefox version spends 6 weeks in each channel before moving on to the next one in the release train. Features land on the nightly channel, whereas aurora and beta are (meant to be) focused solely on stabilizing these new features. Aurora is less stable than beta, and is intended for users who don’t mind sacrificing a little bit of stability for the newest innovations. The beta channel is intended for people who want to try out new features in the next version of Firefox, but don’t want to sacrifice the stability that they are used to.
What pops out at the end of the 6 week beta cycle is the next Firefox release.
Ok, so what’s the point in this blog post?
With each Firefox release spending 6 weeks in the beta channel, there is no point in wasting all of this time by using only 7 days of it for testing in Ubuntu. To make the best use of this 6 weeks we provide our own beta PPA for Ubuntu users, which tracks the upstream beta channel. Builds are provided for all Ubuntu releases. This PPA is the Firefox equivalent of the proposed pocket for other Ubuntu packages, with the following extra advantages:
- It provides 6 weeks of testing as opposed to 1 week
- Users can opt in to it and use it continuously as their default browser. After 6 weeks, they will just get the next beta and the whole cycle starts again.
Some additional information about this PPA:
- It is still possible to send crash reports directly to upstream, just like you can with the version in the official archive.
- It is possible to report bugs to Launchpad in the usual way (using Apport).
- We provide all associated supporting packages, to make the user experience as smooth as possible.
- It’s supported by the Ubuntu developers who provide Firefox for you.
Don’t be afraid of the “beta” name – these builds are much closer to RC quality than beta, and experience so far has shown this to be the case even at the start of each 6 week beta cycle.
So, what can I do to help?
Well, first of all, start running the Firefox beta if you aren’t already. If you’re on the development release of Ubuntu, then you are already running it. If you aren’t, then just run:
sudo add-apt-repository ppa:mozillateam/firefox-next && sudo apt-get update && sudo apt-get upgrade
That’s all there is to it! Now you can start enjoying the next Firefox release
You can also help by blogging and tweeting about this, and telling your friends and family about it.
B…b…b…but, I prefer to stick to official packages rather than use PPA’s, and I can still report bugs and help you if I stick to the release build
Yes, of course you can. But it’s way too late to be finding bugs and regressions in the official release build – by this point, we’ve already shipped it to our users as a security update. It’s much more helpful for people to find and report regressions before it ends up in the archive as the next security update.
I generally believe that anybody involved with Ubuntu Development in any capacity who runs Firefox should at least be using the beta releases all of the time.