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)."
#1 Help out with BugDay!
Tuesday June 27th, 2000 4:30 PM
I know some people think it's "a lot of working" doing QA, but it's not. If you could verify just 10 easy duplicate bugs a day, you're helping out -- a lot. As we approach Mozilla 1.0 and Netscape 6, we need to start cleaning out the bugzilla database to absolutely zero (zarro, in bugzilla terms) open or resolved bugs. When every bug in the list is verified, we can release -- but we need your help to do this!
We would be highly appreciative if you would set aside a couple of minutes each day just to "handle" ten or more bugs...by "handle" I mean triaging and confirming unconfirmed bugs, or verifying any kind of resolved bug. Once you get in the habit of doing a set number of bugs each day, it will go fast! We don't encourage, however, that the quality of your work worsen because of pressure or deadlines -- we always prefer good QA over fast QA :)
Thanks for your time in testing Mozilla!
Zarro Boogs? There are over 5000 open browser bugs. If Mozilla 1.0 is going to be released in a reasonable time, then you're going to have to start resolving a whole lot of bugs won't fix. I don't think this would be a good idea for the RFEs and probelly a lot of other bugs. If things are that far along maybe it's time for a new state in Bugzilla. Post Release or Mozilla 2.0 .Basically this state would be for bugs that won't be fixed for 1.0 but would be preserved as a starting point for work on the 2.0 release. Then a lot of RFEs, milestone future, resolved future, and trival bugs could be moved to this new state and would be out of the way for a 1.0 release.
I don't think RFE's count, as you can never get rid of these. 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'.
#7 Re: Re: Re: Help out with BugDay!
Wednesday June 28th, 2000 8:59 AM
Then there will never be a Mozilla 1.0. The same day that you check in the fix for the last known bug you will get at least 10 new valid bugs reported. Also fixing some bugs is high risk. Fixing them is possible, but carries the risk of introducing a dozen new bugs. If the high risk bug is trival is it worth creating new major bugs over? It depends on where you are in the development cycle. Early in the cycle, you can say yes because there's time to fix the new bugs. When you get near release time you have to either resolve these "won't fix" or move them to the next development cycle. I Think moving them is the better choice and that's why I proposed a formal way to do this. I can think of another way. We could do like a certain company and state "That's not an issue, that's an enhancement" A new resoulation catagory could be created "Enhancement" ;-)
True. OK, I say there should be zarro boogs (or whatever it is) that do not fit into any of the following cats:
1) An RFE
2) Younger than a month
3) High risk, low benefit
Any more people can think of? (sorry if the lines are messed up, I did my best)
>If you could verify just 10 easy duplicates a day.
May be I am doing something wrong, but I need something like an hour to verify that an unconfirmed bug is really a duplicate. 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. May be I am looking for the difficult bugs but the statement would require to spend something like 10 hours per day in bugzilla, that would be fun. But I have to earn money also in the regular way. So I think one good dupe a day is a good dose. Especially wrong dupes are bad.
About the zero bugs: I lost completely any optimism, just count the new bugs per day (have seen 166). 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.
#2 Thanks to everyone that turned out
Tuesday June 27th, 2000 9:33 PM
Thanks to all of you that participated in another productive BugDay, especially all the first time participants! Looking forward to next week....
Asa (remember when posts with mozilla were a rare thing)
#3 Re: Thanks to everyone that turned out
Tuesday June 27th, 2000 10:16 PM
Yes I think many of us remember the time... But still Mozilla is not as good as Netscape in that kind of things. Somethimes it still doesn't work! But I know, that someday it will be much better than Netscape 4.x or any other browser! I trust in you, mozilla.org people.
Indeed, there is a lot of work left to be done before we reach Mozilla 1.0 There are going to be bugs reported in Bugzilla which do not get fixed by Mozilla 1.0 But there are going to be even more bugs left in Bugzilla after 1.0 if we don't all help out. I approach this with the idea that if a developer can write code rather than triage bugs we will move farther and faster. So I spend some time in the Bugzilla database triaging, confirming, and moving and and verifying bugs. I also spend considerable time helping others get involved in the same kinds of activity. This saves the developers time and means that they can work on more of the bugs that concern me. If you are interested in getting involved, getting more involved or helping others get involved please stop in on IRC #qa and #mozillazine and let me know. I can also be reached by email.
the community makes mozilla (and netscape6) possible. without us they will not succeed.
Unfortunally my work scedule has prevented me from joining bug day. I would like to suggest something you could attack on the next bug day though. There are a lot of bugs that have fixes attached to them that haven't been checked in. I can think of two. One is a bug I submitted over a month ago. bug 39984. shortly after I submitted it a fix was attached. This bug has had 2 dupes submitted so far. It's still new. Another is one I suggested an improvement to the patch, and the submitter agreed and added a patch with my sugestion. bug 39231. It's also still new. Both of these have are very low risk fixes and could be resolved and verified fixed quickly. I'm sure there are a lot more bugs like these. IDing them and getting them checked in would not only cut down on the nunber of open bugs, but it would also prevent having to deal with any more dupes of them. I'm not blaming the person these bugs are assigned to. One of them is minor, the other trival. I'm sure he has more pressing bugs to worry about. Which brings up another benifit to my sugestion, Even though I'm talking about easy fixes they still require some time to review and check in so taking care of them for the owners will free up time for the bugs that need real work.
now at Beijing, so far away isn't it? i report the progress of mozilla in the internet section of the site of my company--hongen oline <http://www.hongen.com> one of the most considerable education content provider and the BIGGEST education software provider of China. and many eyes keep on you. go on guys.
#11 Re: the confusion
Thursday June 29th, 2000 3:04 PM
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.