Auto-UNCO: Stage 1 Completed

I’ve just finished changing 12,342 bugs :-) Bugmail was temporarily turned off, and Bugzilla chewed through them in just over half an hour, which is pretty impressive. In about an hour’s time, the daily “send unsent bugmail” job will run, and find itself with rather a larger task than normal…

As I sat there watching the list of people-to-be-emailed scroll by, I thought “Poor timeless” ;-) For some unknown reason, he seems to watch just about everyone. But then I realised that he has a Gmail account. As demonstrated by the JavaScript counter on the home page, Gmail has an ever-expanding mailbox quota. We calculated that we could send him a bugmail every two minutes indefinitely and he’d never run out of room! (No, this is not a call for someone to write a script…)

An interesting thought: if you read the counter’s JavaScript, you can work out that it’s designed to reach 2950MB on exactly January 1st, 2006, and pause there. I suspect they will wait until there’s a good PR opportunity to announce that they’ve upped the limit to 3GB :-) Justdave‘s theory is that they want to hit PI GB (3.14159GB) on April 1st next year…

18 thoughts on “Auto-UNCO: Stage 1 Completed

  1. “Justdave’s theory is that they want to hit PI GB (3.14159GB) on April 1st next year…”. They should consider renaming Gmail to PIGgy Bank then.;-)

  2. Will there be an auto-resolve of too long unconfirmed bugs automatically done in the future ? That is, a mean to get an unconfirmed bug enter in the “pending” status exactly when it reaches 3 months of unconfirmed state, and auto-resolve as “expired” two weeks later without response ?

    Doing some “spring cleanup” is good, but constantly ensuring that the house remains cleen is better, isn’t it ?

    (I may be awfully wrong, as ever)

  3. It would be interesting to know how many of those 12k+ bugs get confirmed or otherwise resolved manually because of this warning. 3 hours after the resolution, 23 bugs have already had their resolution changed (most to dup/wfm/inv). At this rate, the 12,342 bugs will be all resolved in 1,609.8 hours (or 67 days). Gerv is speeding up time by almost a factor of 5!! :)

  4. I entirely support such auto-resolving feature+measure. Bugzilla and QA people have been hoping for such feature for a long time. 12,342 bugs is pretty much what I expected. Many inactive+unconfirmed bugs
    – are/were unconfirmable bugs to begin with,
    – impossible to investigate, no testcase, no working URL, etc.
    – are bugs with not enough useful info with reporters never answering back any questions,
    – etc..
    which were clearly counter-productive and were objectively abusing/wasting the efforts, energy of good willing volunteers QA people involved.

    I also entirely agree with _FrnchFrgg_. It is a good thing to see “spring cleanup”. But it is furthermore wise and justified to establish good cleaning habits. Some sort of pending [inactivity] status for unconfirmed bugs could be implemented.

    G�rard

  5. If they’re clever they’ll try and hit pi around march 14th, known in the math departments around the globe as “PI DAY!”

  6. I don’t know why my first comment here didn’t appear…

    I really wish you’d bothered to set up a READY state before doing this.

    I also really wish you had not done this to components where we explicitly asked this not be done (layout in particular).

    The next time you decide to do this, please either have a READY state available or leave out the following core components: DOM, all layout components, all “HTML:” components, style system, plugins.

  7. Boris: State NEW is basically the same as your proposed READY state. Confirming bugs which being worked on is an easy way to keep them away from the UNCO cleanouts.

    I don’t remember the discussions about not doing it for layout; I remember Bernd being insistent that we don’t touch bugs with the testcase keyword, which we didn’t do. If we did agree this and it’s got lost, I can only apologise :-(

  8. I’m really bummed to see this done to the networking bugs. As I go through them this morning, I find that many of the unconfirmed bugs are indeed valid. I would be surprised if we get all of the reporters clammoring to keep their bugs alive. Instead, I suspect that many of the bugs will end up being closed even though they are actually valid bugs. I’m told that this AUTO-UNCO business was announced well in advance, but I missed the annoucement. I guess I didn’t read the right blog?!? I think it would have been better if module owners were contacted directly via email before this change was implemented. Moreover, I think you couldn’t possibly have picked a worse time to implement this change. I’m sorry to be such a pain, but right before we are to ship 1.5 is not the right time to muck around with the bug system :-(

  9. I fail to see much of a problem. If valid bugs get this message, then either the reporter will comment, or someone will reopen it when they too discover it. How is it worse than the bug being unconfirmed? When would it become confirmed if it was valid? Most likely when someone discovered it, in which case it’s not too much more difficult to reopen than to confirm. If the bugs hadn’t seen any attention for 3 months and were unconfirmed, then they’re not going to be missed. If you were going to look into them and confirm or resolve them, then you can still do this, either normally within 2 weeks, or by searching for EXPIRED bugs in your component.

    I don’t think this is as disastrous as some mention.

  10. Followup to my previous post:

    As of 14:49PDT, 452 bugs from the autoresolve had their status changed. They break down as follows:
    147 now marked NEW
    56 INVALID
    27 WONTFIX
    43 DUP
    112 WFM
    and 2 are magically back at UNCON

    There are about 70 that somehow are not showing up in my variations of the status/resolution field. However, it’s pretty clear that at this point, most of the original UNCON bugs were either marked as NEW or WFM (probably due to fixes in the source since they were filed; might have really been dupes of something else, or just silent fixes).

    At the current rate of resolution, the marked bugs will all have their status manually changed in 13.5 days if the current trend holds (of course it won’t). I will try to remember to revisit these statistics in about 1 week to give people more time to see their tagged bugs.

    However, from first glance, it seems to me that what’s really happening is that people see their bug is going to be put to sleep and they do comment to keep that from happening. This might be biased however by eager early responders, which is why I’ll try to do this again in a week to see if the rate has slowed down/sped up and how many bugs actually get human attention.

    ps. in the time it took me to write this, 15 more bugs had their status changed…

  11. > I don’t think this is as disastrous as some mention.

    YOU clearly didn’t get the volume of bugmail I did from this.

    I have, at this point a few hundred bugmails from people messing with bugs that I have to wade through. This is excluding all the mails gerv actually generated, which I just mass-deleted. These are the responses. And there’s no way to filter them out.

  12. djc,

    The problem is that bugs that get closed by this system will be difficult to discern from bugs that were closed in the normal way. Now, when I wish to triage existing bugs, I have to include closed bugs in my search. That doesn’t sound good to me. The same goes for duplicate resolution of bugs. It’s often the case that people search existing bug reports to see if a problem their seeing has already been reported. It doesn’t make sense to search closed bug reports for a problem that exists in the current nightly build. So, those duplicates will be lost even though they may contain valuable data.

  13. When this was discussed last, it was established that when the bugs are autoclosed they would be marked RESOLVED | AUTOCLOSED, not anything else. I assume this is still the case? If it isn’t please contact me directly since I don’t normally read this blog.

  14. >I remember Bernd being insistent…
    Thats not correct I tried heavily to opt out from this desaster. I recognized that this is a aviary driven decision, which told me that I have no say. Then I tried to limit the desaster. Since I did not and do not want that bots triage bugs that I care about, I was forced to make several sweeps trough the unconfirmed table bugs, not that I wanted to do it but its not bad anyway. However this is not a option for people more active than me like Boris.

  15. Next time you should probably exclude all non-windows/mac/linux platforms. They’re less likely to need it, and I’ve seen a few comments elsewhere about that.

  16. Moreover, I think you couldn’t possibly have picked a worse time to implement this change. I’m sorry to be such a pain, but right before we are to ship 1.5 is not the right time to muck around with the bug system :-(

    That’s what people said before 1.0 as well. There’s always someone who complains that it’s not a good time. There is no “good time”.

    The problem is that bugs that get closed by this system will be difficult to discern from bugs that were closed in the normal way.

    That’s not true; they will be RESOLVED EXPIRED.

    I have, at this point a few hundred bugmails from people messing with bugs that I have to wade through. This is excluding all the mails gerv actually generated, which I just mass-deleted. These are the responses. And there’s no way to filter them out.

    But that’s what’s supposed to happen! Of all the old UNCOs, those are the ones that you should get your QA team to concentrate on, because they are much more likely to be valid. Delete all the mail if you want; but get QA to do a query for them and triage them.

    However, from first glance, it seems to me that what’s really happening is that people see their bug is going to be put to sleep and they do comment to keep that from happening.

    Assuming they are people, preferably the reporters, who know the bugs are definitely valid, that’s great. That’s what’s supposed to happen.

  17. This is not the right way to proceed. It would be better to create a category “outdated” and not to count them as bugs unless they are reactivated.

    There are many old unconfirmed bugs which are still there.