Solve real business challenges on Google Cloud and run workloads for free. For Slashdot users: Get $300 in free credits to fully explore Google Cloud. Get started for free today.
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.
How often do people get modded up on slashdot for posting entries that are nothing more than public docs on a project, links to an obscure mirror of the article or the like? They're not insightful or anything, just basically a rehash of information. The mirrors for example could easily be put into the article post under an update heading.
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.
It seems like every slashdot link I click on, I have to coral-ize myself. Can we all just start supplying these when submitting articles? The world would be a better place.:-)
No particular group, IMO. The Mozilla Suite will remain for those who prefer it over Firefox, but as for marketing, there was very little marketing by the Mozilla Foundation, and that's unlikely to change.
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.
Wow, finally somebody not whining about discontinuing (killing) my beloved seamonkey:) In the dark ages I used Netscape, Mozilla is still like that program UI wise, only the rest of it is way better nowadays! I've been following and using Mozilla since around M12 or so, I actually like Seamonkey better than Firefox. Since Firefox and Mozilla proper share the same back end (Gecko, Necko and friends) there is no real reason in my mind to kill Mozilla proper anyway.
I use Mozilla at home because I want an integrated browser/mail solution. I use Firefox at work because Outlook/MS Office is mandated.
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.
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:-) (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.
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
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.
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?
Just FYI, my original user ID # was 652871. I used it when I was immature and have since dumped it so that my formerly "Terrible" karma doesn't keep my comments from being seen.
I'd have to say its probably not what they are doing, but what MS isn't doing and that is patching their holes. Really, I got my wife to switch to Firefox after yet ANOTHER install of xp because of malware/spyware infections. There is another user due to the holes in IE.
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.
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:
Global averages may not always be relevant to your web site. D
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?
"What is the relationship between Mozilla and Firefox development/releases?"
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.
That's what I thought, but then I noticed that some Firefox bugs don't appear in Mozilla, and vice versa - according to status reports from their respective developers. I suppose the bugs could have been introduced in the refactoring, but these specific ones didn't seem related to that operation, to my uninformed eye.
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.
Not true. Firefox uses the same technology [XUL, Gecko etc.] but IS not "the same with some name changes". Originally Firefox was based on Mozilla but but they redesigned it step by step. First taking out the mail UI and prefs and then redesigning the UI and adding Firefox only features, extension manager etc etc.
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.]
"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.]"
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.
There's one shared core with different user interfaces built around it. If there's a bug in the page layout code, that's in the core, and fixing the bug automatically fixes it for all Mozilla browsers. If there's a bug in the user interface, that needs to be fixed once for each different Mozilla browser.
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 did
As far as I know, Mozilla suite and Firefox are different scripts running on the same engine (as thunderbird). So, bugs on the engine are corrected on the same time for both, but bugs ont he scripts (inteface) are unique for each one. Yes, the app competes, isn't it good?
They are two different user agents build around the same rendering engine (and other libraries, like network). So rendering bugs fixed in one will help the other.
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.
Thanks for that detailed clarification (and guided tour:). It sounds like "Mozilla" has finally arrived as a platform of clients. Combined with Tomcat, Apache and Postgres, it's a network platform. This is going to get really good:).
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.
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. The idea of a branch is to get a stable set of features and bugs. If development took place on trunk, then as g
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