Forums Down

Friday December 14th, 2001

As you may have noticed, we've taken the forums down, as we are hitting our bandwidth limit with them. We're working on getting them up and running again as soon as possible.

In related news, we've added a link to our Cafe Press store where you can get cool MozillaZine appearal, which will help us keep ads off the site for good. Thanks for all your support.

UPDATE: Many people have requested some way of donating money to help us out, so we have setup a paypal account for you to do so. Simply go to and use the email address to contribute. We thank you greatly for all the help, and thank the people who bought stuff at CafePress for the support as well.


#33 Re: Re: Re: Rating

by strauss

Monday December 17th, 2001 1:52 PM

You are replying to this message

> Yet you seem to think that your analysis of Mozilla progress is somehow more accurate than people who are intimately involved with Mozilla on a daily basis.

Nope, I'm basing my conclusions very closely on tyhe reports of people who do run the nightly builds. They report that the nightlies have been extremely unstable all month, and almost every day, they have reported major features dropping in and out. I'm very familiar from my software development career with what that means about the overall stability of a project.

As for you, I'm getting more and more sure that the loudest advocates of the Mozilla open source process have never before been involved with shipping a large software project, and do not have the background or training to understand what they are seeing.

> You have frequently suggested a need for root cause analysis, but you have never to my knowledge explained what you think it would accomplish.

Root cause analysis is a standard quality technique which applies equally well to any project, and is not confined to software. It is an attempt to analyze problems to find out which components of the overall system they have in common. Once a set of data on problems is built up, it becomes possible to find through statistical methods which components are tending to cause the most problems. The reasons for the instability caused by that component can then be analyzed in detail by QA engineers, and they can formulate proposals for changes to prevent or minimize further problems from that component.

> BTW, nightly builds are part of the live debugging process and thus are not expected to be stable on a regular basis.

Again, that's just not how it works. If new checkins break existing features on a regular basis, there's a serious problem with system fragility. A system of this type will probably never achieve the stability needed to ship. The problem can't be solved piecemeal by fixing more bugs, since every bug fix carries with it a large probability of creating a new problem. Fragility has to be solved on a system level.