Updated: Mozilla Community Contributor Departs Over Bug Handling 334
An anonymous reader writes "A blog post published by Mozilla community contributor Tyler Downer claims the Mozilla Triage QA process is broken, and he believes that the rapid release implementation does not work with their current method of handling bugs. Quoting: 'I understand that change takes time, and there is always a delay between planning a change, and the implementation. But with Triage, time is our enemy. We currently have 2,598 UNCO bugs in Firefox that haven’t been touched in 150 days. That is almost 2600 bugs that have not been touched since Firefox 4 was released. ... In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5,934. While this is an improvement, that is 6,000 bugs in Firefox that could be shipping today, and enhancements that could be making the web better (of course it isn’t that high, but the potential is there). This is several thousand contributors that we have told "Thank you for filing a bug report with us. We don’t really care about it, and we are going to let it sit for 6 months and just ask you to retest when you know it isn’t fixed, but thank you anyway."'"
Update: 08/29 19:46 GMT by S : Downer has made another blog post clarifying the bug issue. Updated title and summary to reflect that he was a volunteer, not a Mozilla employee.
Zarro boogs found (Score:5, Interesting)
Oh how the times have changed. For info about QA for Netscape 4.0, see this short refresher course:
http://en.wikipedia.org/wiki/Zarro_boogs [wikipedia.org]
--- cut here --
The following comment is provided in the Bugzilla source code to developers who may be confused by this behaviour: ... way back when, when Netscape released version 4.0 of its browser, we had a release party. Naturally, there had been a big push to try and fix every known bug before the release. Naturally, that hadn't actually happened. (This is not unique to Netscape or to 4.0; the same thing has happened with every software project I've ever seen.) Anyway, at the release party, T-shirts were handed out that said something like "Netscape 4.0: Zarro Boogs". Just like the software, the T-shirt had no known bugs. Uh-huh. So, when you query for a list of bugs, and it gets no results, you can think of this as a friendly reminder. Of *course* there are bugs matching your query, they just aren't in the bugsystem yet...
Zarro Boogs Found
This is just a goofy way of saying that there were no bugs found matching your query. When asked to explain this message, Terry Weissman (an early Bugzilla developer) had the following to say:
I've been asked to explain this
--Terry Weissman
Important Points; But Not a "Community Lead" (Score:5, Interesting)
Mozilla has no such position as "Community Lead". Tyler was/is (he is still engaged in constructive discussion) a valued volunteer member of the Mozilla QA and triage community, but he does not have the title "Community Lead".
There are several things which Mozilla's new more rapid release process has made a bit rocky, as Johnathan Nightingale, the Firefox development manager, noted in a recent blog post [johnath.com] (syndicated at the Future of Firefox blog [mozilla.com]). This is one of them.
And, of course, when Tyler says we have told bug reporters we don't care about their bug reports, that's not actually true. He is suggesting that this is what it might seem like. And clearly, it's not great when a bug report is filed and just sits there for months. Mozilla's success has made this a perennial problem for the last decade. We've cracked it, to a degree, before and I'm sure we can do it again.
Before the flames begin... (Score:5, Interesting)
Just to clear some things up and possibly prevent irrelevant posts...
This has nothing to do with the rapid-release; he states in the 2nd paragraph that
First off, I did not leave because of rapid release. I love the idea of rapid release, and I think the recent spurt of posts to the planet on how Rapid Release will be beneficial in the long run does a great job of explaining it.
His issue is that Triage isnt good enough for rapid release-- not that rapid-release doesnt work with Triage (but thanks for stirring the muck, anonymous reader / soulskill).
But Id like a clarification-- if there were 13,000 bugs 15 months ago, and now there are 6000, doesnt that speak to massive improvement? Why not leave back in spring 2010?
Re:Before the flames begin... (Score:4, Interesting)
Goal is great software, not closing bugs (Score:4, Interesting)
Mozilla's objective should be to release great software, not to close bug reports. In fact, if they can release the software while touching fewer bug reports, that's more efficient.
The problem is that Mozilla continues to be careless about setting their community's expectations (on other issues too). They solicit bug reports from people, who invest time and effort in reporting, testing, following up, and even patching -- but then Mozilla does nothing with the bugs. It's disrespectful to use people's time like that.
Mozilla needs to set expectations clearly from the start: Feel free to report it, triage it, patch it, etc., but realize that most bug reports are never implemented.
Re:Important Points; But Not a "Community Lead" (Score:4, Interesting)
We do care about bug reports, and we try and appear we care about bug reports - both by saying that we care, and trying to handle them. But Tyler is suggesting that our failure to handle all of them means that it might appear that our actions speak louder than our words.
If you want to help the two match up, do get involved with Mozilla :-) We could always use more help. Triage is how I got involved, over 10 years ago.
Mozilla Foundation is badly managed. (Score:4, Interesting)
Add-ons are the reason people use Firefox. Decisions are made that break Firefox Add-ons, without notice.
Firefox is extremely important because it is the only browser that has such an extensive list of add-ons. (Unfortunately, Add-ons are also called "extensions" and "plug-ins".) For some uses, the add-ons are so convenient that they can be considered necessary.
Firefox instability corrupts the Windows operating system. There is huge instability seen only by people who open many windows and tabs, and leave them open for a long time. (It is not necessary to say you don't experience this bug if you don't commonly have 30 or more windows with 100 or more tabs open for several hours. Those of us who must do research have needs different than the average user.) That particular Firefox instability has been there since version 1, perhaps 10 years ago. An example: Two days ago I had a crash in Firefox version 6.0 that did not generate a Talkback report.
Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs (Last updated in 2009.)
Here are the top 20 things Firefox and Mozilla developers say to those who report difficult bugs, collected over the last 8 years. See also the extensive information provided in this Slashdot comment, Firefox is the most unstable program in common use [slashdot.org], and the links in the comment.
Re:Mozilla Foundation is badly managed. (Score:4, Interesting)
Mozilla Foundation has always been badly managed. In the beginning it was managed by Winifred Mitchell Baker, a socially backward lawyer with no technical experience.
Add-ons are the reason people use Firefox. Decisions are made that break Firefox Add-ons, without notice.
Firefox is extremely important because it is the only browser that has such an extensive list of add-ons. (Unfortunately, Add-ons are also called "extensions" and "plug-ins".) For some uses, the add-ons are so convenient that they can be considered necessary.
Mozilla is not breaking add-ons anymore. Now, addons are scanned by a bot and if no problems are expected, the addons compatibility version range is automatically extended to the current version. I have seen this with my addons.
Addons are themes and extensions. Plugins are something completely different, for instance Flash and Movie players, i.e. implementations of the nsplugin-api. This is clearly defined by Mozilla.