Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet

The Mozilla Release Process 59

Posted by CmdrTaco from the every-time-you-ask-we-delay-it-one-hour dept.
David Gerard writes "Asa Dotzler from the Mozilla Foundation invited questions on his blog on the Mozilla release process. The answers are up."
This discussion has been archived. No new comments can be posted.

The Mozilla Release Process More

The Mozilla Release Process

Comments Filter:

  • You call those answers? -1, Redundant (Score:5, Insightful)

    by Anonymous Cowherd X ( 850136 ) on Tuesday January 18, 2005 @08:30AM (#11394184) Journal

    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.

  • The answers are up... (Score:3, Funny)

    by Anonymous Coward on Tuesday January 18, 2005 @08:31AM (#11394197)
    ...and thanks to the Slashdot effect, they're down again.

    • 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. :-)

  • Relating Firefox vs. Mozilla (Score:5, Interesting)

    by cablepokerface ( 718716 ) on Tuesday January 18, 2005 @08:33AM (#11394206)
    So, what exactly is the group of users the mozilla browser targets now with firofox out and all?

    • Re:Relating Firefox vs. Mozilla (Score:5, Interesting)

      by 0x461FAB0BD7D2 ( 812236 ) on Tuesday January 18, 2005 @09:05AM (#11394379) Journal
      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.

      • Re:Relating Firefox vs. Mozilla (Score:1, Interesting)

        by Anonymous Coward
        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.

        Why can't Firefox users be just that ... F

    • Re:why Mozilla (Score:1, Insightful)

      by Anonymous Coward
      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.

  • In case of /.ing: (Score:3, Informative)

    by koi88 ( 640490 ) on Tuesday January 18, 2005 @08:37AM (#11394226)
    Copy&paste:Here's TFA (the answers):

    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

    • Hey, folks - listen up. (Score:4, Insightful)

      by millennial ( 830897 ) on Tuesday January 18, 2005 @09:04AM (#11394372) Journal
      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.

  • Mozilla/Firefox (Score:5, Interesting)

    by Doc Ruby ( 173196 ) on Tuesday January 18, 2005 @08:51AM (#11394298) Homepage Journal
    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.

      • Re:Mozilla/Firefox (Score:4, Informative)

        by Rogue Pat ( 749565 ) on Tuesday January 18, 2005 @09:08AM (#11394395)
        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.

      • Re:Mozilla/Firefox (Score:2, Informative)

        by starwed ( 735423 )
        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.

    • Re:Mozilla/Firefox (Score:4, Informative)

      by ToLu the Happy Furby ( 63586 ) on Tuesday January 18, 2005 @11:33AM (#11396414)
      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 :).

  • Doug's Questions (Score:5, Insightful)

    by bokmann ( 323771 ) on Tuesday January 18, 2005 @09:10AM (#11394425) Homepage
    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'.

  • Process (Score:4, Interesting)

    by marvin2k ( 685952 ) on Tuesday January 18, 2005 @09:46AM (#11394842)

    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

Slashdot Top Deals

Avoid strange women and temporary variables.

Close