Slashdot Mirror
The Mozilla Release Process
David Gerard writes "Asa Dotzler from the Mozilla Foundation invited questions on his blog on the Mozilla release process. The answers are up."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Copy&paste:Here's TFA (the answers):
:-) (hours, not minutes) so I haven't done any serious proof reading; please excuse grammar or spelling issues. Also, this is just one man's opinion and if I've got something wrong here or misrepresented anything, pin that on me and not on drivers@mozilla.org or other members of the community.
:-)
I promised I'd get to all of your questions from my making releases happen post and I've finally got a few minutes free to take a stab at it.
Some of the questions overlap and some would take a lot more time to answer than I've got for this post but I've done my best to put together replies to each of the questions. I'm put my responses together in the format of direct replies to each of the people who had questions. Maybe later I can distill this into a more condensed post about the release processes at Mozilla.
This took a good bit longer than I expected
Peter van der Woulde was the first to post questions, so he gets the first set of answers.
1. How do you decide what to plus and what to minus ?
This is probably one of the most frequently asked questions and our process isn't based on a set in stone list of rules. As I'm sure you know, there are two types of flags we evaluate and set. The first is the "blocking" bug flag and the second is the "approval" patch flag. The blocking flag is for bugs which should stop the shipping of that particular release and the approval flag is for patches which should land during the freeze for that release.
It's probably also important to realize that there are about a dozen of us on drivers@mozilla.org and we all come with different expertise. I am particularly focused on quality and how our testing and user communities will respond to each of the product releases. Others have a focus on things like Web standards, security, freezing and maintaining APIs, or the Mozilla application platform. We all approach the plussing and minusing of bugs and patches with a somewhat different set of criteria.
There are a lot of factors that come in to play, but I think over the years all of drivers have come to settle on some basic tenants.
First, our criteria for alpha, beta, and final cycle changes are all different. We're going to have a different approach to determining whether or not a bug should block an alpha release than we would for a final release. We're also going to be a bit more relaxed about the kinds of patches we approve to land during an alpha freeze than we would for a final release freeze.
Alpha cycles can absorb more risk than beta and final cycles so we're likely to try to use drivers@mozilla.org's influence to get high risk patches (including features, major code rewrites or reorganizations) landed in the alpha cycles. I'd certainly rather hold an alpha release for a day or two in order to get the added testing on a major new feature before beta and I'd be willing to approve the landing of that change during the alpha freeze when I might push out lower-impact changes to the beta. It is sometimes a bit odd that we approve higher risk changes and deny lower risk changes, but there's some sanity behind it
In a beta cycle, we are working to get our features in and all of our localizable resources frozen so we chase down any last feature changes, especially those with localizable strings. Our blocking and approval flag setting during beta are heavily influenced by our desire to get those changes all settled so that our testing and localization communities have a clear idea of what we plan to ship by final and we can get good testing coverage and as many complete localizations as possible.
During the final cycle, usually on the branch, we're all about minimizing risk and preventing changes that would break localizations. In addition to those criteria, we are looking for spit and polish changes, stability improvements (any low-risk topcrash fixes) and those routine chan
I don't need a signature.
At bugzilla you can file bugs against the suite [mozilla browser+mail], firefox [a browser-only implementation], thunderbird [mail-only implementation] and core components [covering "rendering", "dom", "forms" etc etc.]
Apps based on the Mozilla codebase (Firefox, Mozilla Suite, Thunderbird, Camino, Sunbird, NVu, etc.) are developed on a trunk-and-branch system. The "trunk" development stream is where all the heavy lifting and generic improvements to the core components get done. The core components all those apps share include things like Gecko (XHTML/CSS layout engine and DOM), Necko (networking), SpiderMonkey (Javascript engine), XUL (cross-platform graphical toolkit; not used by Camino), and many more. In addition to these shared components, there is of course app-specific code for each application, implementing that app's interface, features, bug-fixes, etc.
A few months before an app hits a milestone release intended for end-users (i.e. Mozilla Suite 1.8, Firefox 1.1, etc.), a "branch" will be cut from a snapshot of the trunk. Checkins to the branch are meant to get the app to release quality: bug-fixes, interface tweaks, cutting features that aren't quite ready for prime time, rushing in low-risk features with a big impact in end-user usability. (Meantime, checkins to the trunk continue as normal.) The branch will progress through some number of alpha releases, beta releases, and release candidates before culminating in a final point release. Then the branch gets shut down, the applicable bug fixes are merged back into the trunk code, and the process starts again.
Now, at any point you can checkout the entire trunk from CVS and, depending on a couple parameters in your build script, compile it into Firefox, or Mozilla Suite, or Thunderbird or whatever. (Or you can download a nightly trunk build of Firefox or the Suite.) But what you get is by definition in pre-alpha state; you might end up with half-baked features, features not matched up with the UI, and so forth. So trunk builds are mostly just useful for developers (whereas branch builds are useful for both developers and people doing QA).
Lately there's been more divergence between Firefox/Thunderbird and Mozilla Suite than normal because Firefox 0.9-1.0 and Thunderbird 0.7-1.0 were all cut from the same long-lived (7 months or so) branch, which was intended to allow them to get to 1.0 quality. Indeed the major work for the 1.1 releases is just to re-sync them with the trunk. But the plan is for shorter branches from here on out, at least until the 2.0 push.
So to answer your questions: there is a common core project, and most of the core components are shared, although they become out of sync on the branches. It's an open source project, so bugs and features get attention depending on what developers (or their employers) are interested in. It is indeed a point of contention that Firefox and Thunderbird increasingly tend to get more development resources than the Suite, but they both get to take advantage of improvements to the core components. And in that sense, at least, the codebases are not fragmenting; instead they're becoming more similar after a relatively long-lived divergence.
Note that each release of Firefox, Mozilla, Thunderbird or whatever is built off a particular branch of the main codebase. So Firefox 1.0 and the most recent Mozilla version don't share all the same features/bugs. But by firefox 1.1, the underlying Gecko engine will be the same as that to be used for Moz 1.8.
One of the more visually obvious bugs this will fix in Firefox is the infamous "slashdot bug" where the left column isn't laid out correctly. This was fixed quite a while ago in the trunk, but didn't make it into the branch Firefox 1.0 is built from.