Tuesday June 27th, 2000
Asa Dotzler writes, "It's BugDay again! This week we'll be focused on cleaning up Bugzilla. We've got thousands of bugs that need Verification across a wide variety of platforms and the Unconfirmed waters are rising too. So if you're testing current Mozilla builds on an exotic platform/OS, we especially need your help (there are a few thousand mac, linux and win32 bugs that need help too). Hope to see you all there. BugDay can be found on IRC server irc.mozilla.org channel #mozillazine every Tuesday afternoon into evening (USA time)."
#11 Re: the confusion
Thursday June 29th, 2000 3:04 PM
You are replying to this message
Sorry, my comment seems to have sparked a little confusion.
> There are over 5000 open browser bugs
Actually, a search for Browser and MailNews bugs, not including enhancements or bugs with RFE in the summary line, and excluding Future bugs, yielded 3578 bugs. Many of these are old and no longer exist. Some will be invalid or wontfix. Others will be dups. I'd honestly predict that about a little less than half of those 3578 bugs can be closed up one way or another (i.e., not fixed). Many of the remaining ones will need to be deferred to after the Mozilla 1.0 release. However, we can't just release the browser when there are open bugs that haven't been handled (unless we wanna pull a win2k)
> maybe it's time for a new state in >Bugzilla. Post Release or Mozilla 2.
We already have one...two, actually. The older, deprecated RESOLVED | LATER or the newer Future milestone.
>I don't think RFE's count, as you can >never get rid of these.
Well, you can get rid of them by implementing the enhancement request...but I agree that these should not be considered as bugs, hence the reason I didn't include them in my aforementioned query for open bugs.
>But I don't think Mozilla should be >released if there are any known issues >where it hasn't been decided 'a fix is >not possible for this'.
I completely agree, and I'd imagine that the rest of the QA crew would as well.
>May be I am doing something wrong, but >I need something like an hour to >verify that an unconfirmed bug is >really a duplicate.
Nope, you're absolutely right -- unconfirmed bugs are much harder. I was referring to bugs that are resolved as duplicate, but haven't yet been verified. Often, these are almost exact duplicates, and you simply need to compare the two bugs and ensure that they are, in fact, the same problem.
>Usually I write first a testcase to >narrow down the problem, attach the >testcase and then I search for a >duplicate to finish the bug.
That's a wonderful QA practice. Keep it up!
>the statement would require to spend >something like 10 hours per day in >bugzilla, that would be fun.
Welp, I'd imagine that many mozilla.org and netscape QA employees aren't too far off from that figure. But then again, they get paid.
>So I think one good dupe a day is a >good dose.
Yep, as I said, dup'ing open or unconfirmed bugs is much harder than simply verifying resolved duplicates. Do whatever is easiest and comfortable for you, the "10-a-day" was just a suggestion.
>Especially wrong dupes are bad.
Yep, as I said -- good QA is preferred over fast QA.
>About the zero bugs: I lost completely >any optimism, just count the new bugs >per day (have seen 166).
Yes, but many of these bugs fit into one of the following areas:
* Reporter is using an old build or a milestone build to report the bug, thus it's invalid (or wfm) and no longer occurs/exists.
* The bug is a duplicate.
* The bug is a trivial UI change and can be fixed easily.
* The bug is a regression, which are often quite easy to fix.
* The bug is unconfirmed, meaning it hasn't yet been confirmed by QA that it is, in fact, a bug. Many of these turn out to be invalid or wontfix bugs.
* The bug is not really a bug at all, but rather an RFE. Together with the requirement to check in only for nsbeta2+, it makes me believe that we are lightyears away from the TeX-bugfree state, I would dream of.
>I approach this with the idea that if >a developer can write code rather than >triage bugs we will move farther and >faster.
Agreed. A developer should be able to look at a bug for the first time and have all the necessary information at his finger tips (reproduction information, talkback reports, testcases, and so forth). Every time he or she needs to triage a bug is more wasted time for the developer that shouldn't have happened if QA was around.