The Mozilla Release Process 59
David Gerard writes "Asa Dotzler from the Mozilla Foundation invited questions on his blog on the Mozilla release process. The answers are up."
A Fortran compiler is the hobgoblin of little minis.
You call those answers? -1, Redundant (Score:5, Insightful)
His answers can be summarized as: "It's extremely difficult for me to generalize here." If his blog were a /. post it would get modded -1, Redundant, there is nothing in his answers that people did not know before, he just explained he can't explain how they decide.
Yes, but (Score:2)
The answers are up... (Score:3, Funny)
Re:The answers are up... (Score:2)
thanks to the Slashdot effect, they're down again.
Which means people are RTFA, which confuses me to no end, because on /. you're not supposed to RTFA, but obviously people haven't read the highly rated frist post denigrating the article.
Predicting /. readership is like predicting the stock market...you'll always be wrong.
Seriously, ARTICLE SUBMITTERS: USE CORAL LINKS!! (Score:3)
Relating Firefox vs. Mozilla (Score:5, Interesting)
Re:Relating Firefox vs. Mozilla (Score:5, Interesting)
However, as he said,
"I believe that there will continue to be trunk based releases of the Mozilla application suite because there are members of the community who want it to continue and will contribute the resources to make that happen."
For many Mozicianados aficionados, Firefox will never fully replace the experience of Seamonkey. Firefox was targeted primarily at IE users anyway.
Re:Relating Firefox vs. Mozilla (Score:1, Interesting)
Why can't Firefox users be just that
Re:why Mozilla (Score:1, Insightful)
If I had a choice I would use only Mozilla because, at this time, Firefox and Thunderbird are not well enough integrated. Running both is also extra memory and disk overhead.
In case of /.ing: (Score:3, Informative)
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
Hey, folks - listen up. (Score:4, Insightful)
Remember, friends don't let friends karma whore.
Re:Hey, folks - listen up. (Score:1)
The article isn't slashdotted, so it doesn't need a mirror
How can one know in advance whether or not a particular article will become overloaded? Is there a central list of sites that don't get overloaded easily?
Re:Hey, folks - listen up. (Score:1)
Re:Hey, folks - listen up. (Score:3, Funny)
Re:Crazy (Score:1)
Re:Crazy (Score:2)
Don't get me wrong here, I LIKE Firefox but getting people to switch like my parents or wife takes an act of God. In this case, an act of reinstalling.
W3Schools statistics are biased (Score:2, Insightful)
Firefox/Mozilla usage shot from 8% to almost 20% in the last year. (source: http://www.w3schools.com/
Of course more W3Schools viewers are going to use web browsers based on the Gecko engine; being web developers, they are more likely to have heard of Firefox and to appreciate its value than the general population, who unfortunately still thinks the blue 'e' is Teh Intarweb(tm). This skews the statistics. At least W3Schools admits its bias:
Mozilla/Firefox (Score:5, Interesting)
Re:Mozilla/Firefox (Score:1)
I think you misunderstand what Firefox is. Firefox is just the new name for the browser component of Mozilla. It's all the same open source project, they just changed the naming around a bit.
Re:Mozilla/Firefox (Score:2)
Re:Mozilla/Firefox (Score:4, Informative)
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.]
Re:Mozilla/Firefox (Score:1)
Oops. You're right. I took a quick glance at mozilla.org and just noticed that they've still got the integrated suite available, although it seems to have been deemphasized with the main spotlight on Firefox and Thunderbird.
Re:Mozilla/Firefox (Score:2)
Re:Mozilla/Firefox (Score:2, Informative)
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 did
Re:Mozilla/Firefox (Score:2, Insightful)
Re:Mozilla/Firefox (Score:2)
Re:Mozilla/Firefox (Score:4, Informative)
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.
Re:Mozilla/Firefox (Score:2)
Doug's Questions (Score:5, Insightful)
CMM is a 'process improvement methodology' from Carnagie Melon called the 'Capability Maturity Model'. It is similar in intent, although not at all in style or implementation to process improvement metholodogies like 'Extreme Programming' and 'Scrum'. For level 2, there are 6 'process areas' - the questions asked here are from the area of 'Software Configuration Management'.
It was very interesting that he was able to answer 'yes' to each question, and point to the 'documentation artifact' that proves his point. That is exactly what you are supposed to be able to do during a formal assessment. I'm going to bookmark this and save it for the next time someone rants about 'quality of open source'.
Re:Doug's Questions (Score:1)
Process (Score:4, Interesting)
When I heared of the creation of the Mozilla Foundation I thought that this would be a big step forward since the developers could leave most of the rigid, slow and often over-designed bureaucracy behind but when I look at it today I'm not so sure about that anymore.
The first thing that I'm wondering about is the way the releases are organized. Why was most of the Firefox work done on a branch and then "crash landed" on the trunk? Some of the bugs resulting from this crash are yet to be fixed. Why make things so complicated? If the main development had happened on the trunk and the releases had been branched off of that this process would have been a lot easier to manage in my view. Almost all other open-spurce projects do it like that.
What about the closing of the source tree for releases? For a while I was wondering why so few checkins got made despite the pending release of Firefox 1.1 in March but then I realized that the tree was closed for a Mozilla release instead. This looks a bit like the Big Kernel Lock to me. One process has to wait for the lock to be released even if ultimately it isn't dependant on the resources the lock has been acquired for.
When I read the projects roadmap I had hoped it would get split up in distinct pieces like Gecko, Toolkit, Firefox-UI, etc. which could be developed individually instead of in one X11-like monolithic blob that requires a global closing/opening process. Gecko for example could be shared by Firefox, Thunderbird, etc. and have independent releases that the other bits could rely on just like QT or GTK applications rely on respective releases of these toolkits. A Gecko 1.8 release could be branched off of the trunk and developers could just continue to check in new and potentially dangerous code on the trunk despite any impending release of higher-level components. These would simply rely on the last stable release of the lower-level ones.
Maybe I just get a lot about the Mozilla process wrong because it seems to be quite opaque at times just like the X11 one still is. There still seems to be no clear decision wether X11 is going to be modularized or not for example, just like with Mozilla. Anyway I hope most of this was caused by the first Firefox release and that 2005 will be used to chop Mozilla up in smaller more easier to swallow pieces because otherwise I'm not sure the project posesses the agility to compete with Microsoft for long.
Re:Process (Score:2)
The idea of a branch is to get a stable set of features and bugs. If development took place on trunk, then as g