Auto-UNCO: Stage 2 Completed

OK, so it’s all over. Some stats for you:

Product Bugs Tagged in Stage 1 Bugs Resolved EXPIRED Percentage
Firefox 3188 2544 79.8
Thunderbird 2044 1631 79.8
Mozilla Application Suite 2751 2313 84.1
Core 4353 3231* 74.2
Toolkit 6 3 50.0
TOTAL 12342 9722 78.8

*: not including all Layout components and SVG, which were excluded

You may remember from last time, two weeks ago, my calculations about filling up timeless’ Gmail account. We calculated that we could send him a bugmail every two minutes, and the account would never fill up. Now 14 days * 24 hours * 60 minutes / 2 = 10080. So, with 9722 bugs changed, we are pretty much on target there :-) Anyone got any ideas how we can keep the rate up for the next two weeks?

There are now only 6040 UNCONFIRMED bugs remaining in those five components, which is rather more tractable. If you are in QA and doing UNCO bug triage, I would at first start with bugs which went through this process and were tagged by their reporters as “yes, I still see this”. Let’s see if we can get the figure below 6000 and keep it there.

6 thoughts on “Auto-UNCO: Stage 2 Completed

  1. Gerv, that’s a pretty hefty number of bugs that’re expired. Could you do a count of how many bugs were resolved by their owners after your first warning? I think people’d be interested in that stat.

  2. A quick search for “RESO/VERI and not EXPIRED” in all components w/ the comment “auto-resolve01” lists 815 bugs.[1]

    NEW/ASSI/REOP lists 368 bugs

    FIXED lists 16

    UNCO lists 1443

    Many of the still UNCO bugs have just a new comment saying “can you still see this?” and many have “still visible in 1.0.x”. Another thing is that people removing themselves from the CC list after the auto message, ‘saved’ the bugs from EXPIRED (eg Bug 183053)

    [1] I did not filter out layout and SVG, so might not add up to 100%

  3. Next time we should tell people in what version they should retest, it wasn’t mentioned in the mail. Most had never heard of the Firefox (or Thunderbird) 1.5 betas, and assumed that if it still existed in FF 1.0.7, it must still be a valid bug. One even confirmed that it still existed in FF 1.0.2, the same version where he filed the bug in the first place.

  4. Good stuff. After the first stage I had a look at all of the bugs I was cc’d on to check there weren’t any useful ones (there was 1 out of 50, and someone else had commented to keep it open by the time I saw it). At least a dozen of them were bugs that I’d tried to resolve WFM or INVALID previously, but they’d been reopened by people (reporters mostly) who thought they should be looked at one day when a developer had a few days to spare investigating the vague possibility of a bug.

    Is there any point marking expired bugs verified?

  5. Now a lot of bugs are marked expired. How to go on?
    If a reporter commented WFM, but didn’t resolve wfm, should the bug be
    reopened, marked WFM, and verified, or
    verified expired?
    not verifying these bugs would be a waste of time of people who retest for some reasons, maybe to find a testcase for another bug.

    Another question:
    crasher bugs in Firefox 1.0.7 are marked fixed or wfm, because they work in the 1.5 beta. Shouldn’t a crasher bug filed for 1.0.7 be left open until it is fixed in 1.0.8 nightly?
    Or should a crasher bug fixed on trunk be downgraded to Branch, if it is still crashing on branch.
    As it is, I don’t see how I can get an overview about crash problems in the 1.0.x branch.

    herman

  6. There’s no point marking EXPIRED bugs verified.

    Herman: if the reporter said WFM after the message was sent out, it won’t have been resolved EXPIRED :-) In that case, mark it WFM.

    As for crashers on 1.0.7, they aren’t going to get fixed unless they are security problems.