MozillaZine

Update on 0.9.4

Friday September 7th, 2001

We asked Asa for a quick status on 0.9.4's status, which was for release this weekend, and here's what he had to say:

"Mozilla 0.9.4 daily branch builds are looking good. The mozilla.org Drivers have decided to get some additional coverage on the new "-turbo" mode, and we have added a few days to get it turned on by default in the win32 installer builds (don't worry, you can still uncheck the checkbox in the install routine). This and a few other late fixes have us targeting early to the middle of next week for the release. We're hoping for a good round of builds Monday, and barring any unforeseen problems, release soon after. Any help testing "-turbo" over the weekend and on Monday is greatly appreciated (you all have Bugzilla accounts, right?). The sooner we can find any problems or prove it's working the sooner we'll have our Milestone release."

Preliminary testing is showing -turbo to be a very solid new feature, so with a small amount of testing over the weekend, it should be good to go anywhere from Tuesday on.


#98 you obviously haven't been paying attention

by asa <asa@mozilla.org>

Monday September 10th, 2001 8:15 PM

You are replying to this message

Since the beginning of Milestones (and i was actively testing Mozilla even before that) we have always identified a set of bugs that we'd like fixed for a particular Milestone. Developers, testing and QA community and project management all work to get bugs identified which would make this Milestone worse than the last one. We have never fixed every bug targeted or nominated for a particular Milestone. We never intend to. Milestones are binaries made for testing. They have no significance beyond that and any time spent on the branch is a division of resource that only makes sense as a means to make this Milestone better than the last so that people will use it more than the last one and hopefully find bugs that they didn't find before. That you think otherwise is your misunderstanding of the purpose of Milestones and the effort that goes into making them. I was in favor of binaries but having read your comments I think I'm beginning to see the logic in the early arguments against providing binaries. (mozilla.org didn't always make binaries, you know, and there was serious debate about doing so. people quickly forget that the only reason for doing binaries is to facilitate broad testing and development).

If you think that the total number of reports in our bug database is _the_ quality metric for mozilla you are far from understanding this process. How about the number of blockers today compared with a week ago? Is that not a quality metric? How about the average severity of incoming bugs going down? You don't consider specific quality metrics as valid and you insist that total reports in the database is valid quality metric? Mean time between failure isn't a quality metric?

If you've got ideas about measuring quality that are any more sophisticated than total bugzilla report counts and if you'd like to do some measurements let me know. I can use the help. If you want to insist that you have better idea about the quality of the app that I do but can't provide any numbers or that the app's quality is somehow going down then this is a waste of my time.

Thanks for the help with our schedule. I guess we're long past 1.0 then. The marketplace (companies like Beonex, Netscape, Bloomberg, ActiveState, iPlanet, Galeon, Nokia, Intel, HP, RedHat, IBM and other) have been using Mozilla for a long time. Since they didn't reject Mozilla I guess we meet your criteria for 1.0 (hell, we met that years ago). (1) Many commercial developers and development companies are devoting resources to support Mozilla-based products (Netscape, Nokia, iPlanet, RedHat, Intel, IBM, ActiveState, OEone, HP, others). Many are already shipping products based on Mozilla (Netscape, iPlanet, RedHat, IBM, ActiveState, others). (2) mozilla.org has no intention of "shipping" a product that will be "a significant force in an IE-dominated marketplace". We'll leave that to big companies with marketing and distribution budgets. I can think of a couple and neither of them are waiting for Mozilla 1.0 to start that effort. So, I guess 1.0 is done. We should retroactively rename 0.6 or 0.7 to 1.0 and get the show on the road to 2.0.

You're flat wrong about the Bugzilla and QA activities. It is the unpaid volunteers that triage the overwhelming majority of incoming reports. You're also wrong about "regression rate". What methods are you using to determine that there is a high regression rate? What do you consider high and what metrics support that conclusion. You want to give us a list of all of the regressions that made it into some of the Commercial releases based on Mozilla code? Let's look at Netscape. Can you point me to all the regressions in 6.2 vs 6.0? Is that number unacceptible?

Your're also wrong ab out another point. Lots of people do QA for fun. Some of them are paid, some are not. I happen to be someone that does it for both reasons. Do you have some statistics that demonstrate that "No one does [QA] for fun."? Most of the people I've met in QA are there because they enjoy it. Maybe enjoyment is not the same as fun? I'll look up the word origins later. Is QA such a shitty job that people doing it couldn't possibly do it because they enjoy it? There are other jobs that pay the same or better and require less effort and education. What do people do QA if it is so not fun?

That they can publish and you can read an admittedly "rumor mill" editorial on news.com has nothing to do with any pressures we face to ship an app. If you believe that AOL is putting pressure on mozilla.org to ship 1.0 you are really out of touch with the relationship that Netscape/AOL have had with the Mozilla project over the years.

I'm very close to being done with this thread. You are offering nothing . You criticize the people and the process and don't offer any alternatives and definitely don't offer to pitch in yourself. You don't understand that we're building a technology that others will take to market.

I think I remember you saying that you felt you got burned by getting involved with Mozilla early. It's a shame that you invested before the technology was up to the level you needed it to be. Others invested early, actually paying people to fix the bugs that blocked their particular projects and their efforts are paying off. Talk to ActiveState or Netscape or OEone about their experiences as early adoptors. They all have great products based on Mozilla technologies. Others are doing the same and it gets easier with every passing day. If you don't think Mozilla is good enough for your particular needs you could pay some folks to do development and QA, you could wait until someone else does that work for you or you could find a different solution. I'm glad to help you pursue any of those options.

--Asa