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)
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.
So, what exactly is the group of users the mozilla browser targets now with firofox out and all?
What is the relationship between Mozilla and Firefox development/releases? Is there a common core project, enhanced/stripped for each specific app's release? Is Mozilla or Firefox developed/debugged first, then the other? Or are there just two projects closely related in target market, drawing on each other's open source as it's entered in CVS (or other public code repository)? Do bugs get fixed in Firefox or Mozilla first, or does it depend? If it's the latter answer in the last two questions, won't the two apps inevitably compete, fragmenting their mutual marketshare vs. Internet Explorer?
--
make install -not war
Why mod this insightful? There is nothing insightful about this. This is just as much of a troll as posting long stories about the GNAA taking over some company, or that horrific Old Ike story. All this guy did was copy & paste someone else's work for his own benefit. It's like going to a famous author's book premiere party, and trying to look good by reading the book out loud to anyone who'll listen.
Remember, friends don't let friends karma whore.
I am scientifically inaccurate.
The questions at the end, asked by 'Doug', sound like those of a CMM auditor/appraiser, with vocabulary like "according to a documented procedure" and "affected stakeholders". Sounds to me like someone is interested is assessing mozilla at CMM Level 2...
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'.
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.