There have been numerous reports recently that "Mozilla will not fix 80% of the remaining 700 blocker bugs in Firefox 3". Some Mozilla members call this bullshit, others have expanded with lengthy explanations.
Personally, I tend to think that the misunderstanding about what Mozilla is doing has one single cause: what we call a bug is actually not a bug, but rather a request for change in the product. No, I'm not falling into the marketing-speak trap, calling bugs undocumented features, I promise
A bug, in Mozilla lingo, refers actually to a report listed in the Bugzilla application. In such reports are listed things that we want to track. It could be suggestions for changes, meta-bugs, and even actual bugs including things that can crash the product, induce data-loss and security issues. Thers are the top three categories that we want to address first, as quality and security matter the most to our users and our communities.
So these "700 blocker bugs" are actually 700 changes that some people, at some point, wanted to see happening before we ship Firefox 3 in its final version. Let's be clear, this is too much! Most likely, many of these changes are just potential new features that are late in the game, and won't make it in time for Firefox 3 (hopefully most of them will be fixed in a later version or become obsolete).
This is were programming and product management are closer to art than to science: the Firefox product team needs to decide where to draw the line, because the more we add features at the last minute, the less stable Firefox will be, due to lack of heavy testing. This is why deciding not to fix "bugs" (read "change requests") is leading to a less buggy product (with less defects)!
Some reports here are already explaining this:
- Reports of Firefox 3.0 bugs overblown, most significant bugs squashed. "Reclassifying less-significant blockers is a necessary QA strategy that will actually lead to a better Firefox 3 release."
- Firefox 3.0 bugs: Mozilla sets the record straight.
edit: Post slightly edited in order to fix spelling and grammar issues. Thanks Jane for the help!
10 réactions
1 De jeansagi - 21/11/2007, 18:02
Maybe I'm out of context but if a bug (a stopper) is tagged as a "bug" and a request for change is taggged as a "request for change" then won't be misunderstangins...
J.
2 De reed - 21/11/2007, 20:13
I believe "When a but is actually not a bug" needs to be "When a bug is actually not a bug".
3 De universityupdate.com - 21/11/2007, 20:49
When a but is actually not a bug
...
4 De Gabriel - 21/11/2007, 21:36
Typo dans le titre : When a BUG is actually not a bug
5 De gil - 21/11/2007, 21:53
+1
In several bug tracking systems, we can use two kind of reports, for defects (anomaly report) and change request (evolution report). It should be better to use such a difference.
6 De glattering - 21/11/2007, 22:05
Maybe they wanted to keep bugzilla for everything and not create a new requestforchangezilla
7 De loufoque - 22/11/2007, 01:45
Be it a real bug or not, if it's marked as blocker for Firefox 3, it should be fixed before Firefox 3 is released.
8 De funtomas - 22/11/2007, 09:52
Nope, Tristan. It's pretty clear, Mozilla's fixed over 11,000 bugs related to FF3 and the mentioned number of 700 bugs was related to the remaining bugs at the time of writing.
It's misunderstanding on your part, I think.
9 De Tristan - 22/11/2007, 19:38
Funtomas: thansk, but no
Just look at https://bugzilla.mozilla.org/show_b... to have an example.
10 De Robert Kaiser - 23/11/2007, 15:15
Whole you're absolutely right on a "bug" meaning a "request for change" in Mozilla lingo, and that could even be a documentation change or a feature enhancement (actually, our blockers are often the latter), I can't fully agree with you on that being "700 changes that some people, at some point, wanted to see happening before we ship Firefox 3" as it's not "some people". Those 700 reports were requested to be blockers by "some people", but the people who granted the request and actually made them blockers were "drivers", i.e. members of a groups of people specially assigned to make such official decisions for the project. They decided that those changes should be made for Firefox 3 if possible in any way. Of course, not all feature requests marked there will probably make it and that needs to be rethought for those issues, but telling "it's just a random number of random changes wanted to be seen by a random group of people" makes it too easy.
What it all comes down to is that we all can't have everything we're dreaming about in a software release, so some hard decisions need to be made, and the Firefox team is in the process of carefully evaluating which changes/"bugs" should really make the cut for Firefox 3 and which will probably have to wait for, say, Firefox 4 or whatever the next major release will be called.