Dropping those old crasher reports

Diego Escalante Urrelo proposed to drop <= GNOME 2.16 crash reports on desktop-devel-list. The reasoning (as discussed on bugsquad-list) is:

  1. They are really old and most of them are answered “well yes, try SVN/last-release it [might be] fixed there”, or simply ignored. They only make bugzilla noisy, hence making difficult to find useful reports.
  2. It is unlikely any new crasher will occur. As we’ve been triaging these crashers for over a year, the chance of a new 2.16-specific crasher is not worth the amount of time it takes to triage the dupes.

There hasn’t been much response on above proposal. I plan to implement above as per 30 September, this year.

Clarification: As some people are misunderstanding: This is not about closing existing bugreports with a ‘please upgrade’ (this is up to the individual developers of each product). This is about not accepting new incoming crash bugreports coming from GNOME 2.16 or earlier. This as the chance of getting an actual new crasher (instead of a dupe) is highly unlikely. This coming from the people (not me) who look at the thousands of new crash bugreports arriving each week.

10 Replies to “Dropping those old crasher reports”

  1. It’s not just about queries. It’s about useless bug-buddy reports pouring in. Someone has to spend the time triaging the reports from old versions that aren’t going to be fixed anyhow.

  2. I think it’s really tacky to send a user “Your software is outdated, please upgrade.” or something along those lines if they are on the latest version available for their distribution. If it is the case that no new bugs could be reported from 2.16, then they should be getting a “This bug has already been fixed.” message anyway.

    As an angry bug reported (I hate to admit it, but I usually am), this would just piss me off even more. You should really hold off until the major distros have moved beyond 2.16 in their stable releases.

    – Brian

  3. Just so long as it goes back a couple of releases. There’s nothing worse than finding a nasty bug, submitting it, and having it closed because it *might* be fixed in SVN. (Gee, thanks, I think I’ll waste my weekend figuring out how to download GNOME source and build it all again, just to check this one bug.) Or, just as bad, because it might be fixed in a newer GNOME release which my distro doesn’t have packaged yet.

  4. Brian: I never proposed such a message, nor that we drop 2.16 bugreports. What I proposed was not accepting incoming 2.16 or older crash reports. That is entirely different. The chance of a new crasher is very low.

    It is NOT about ‘this bug might be fixed’. It is about “this bug is likely already reported a couple of hundred times”.

  5. ovitters: That’s not what I was saying. The scenario as is stands is a user of 2.16 submits a report via bug-buddy. From what you’ve said, I would assume they get a message along the lines of “Your version is no longer supported and your bug report will be ignored.” There will probably be more eloquent wording, but that’s the gist of it. If the user is using a MAINSTREAM distribution that don’t yet provide GNOME 2.16, they are left with no solution other than changing distros or using a beta repository.

    I understand the pretty much every bug has been reported, but under the current system, they should be receiving some sort of message along the lines of “This bug has already been reported,” or “This bug has already been resolved.” I don’t see where the need for this really comes from.

    Of course, it is my honest opinion that fixes for crashers should be backported for commonly used GNOME releases, even if all other work on the branch has ceased.

  6. Brian: I misunderstood then.

    But again, I’m not going to say that they should upgrade.

    I can explain the need: We get a minimum of 2000 bugreports/week. This amount is causing a huge workload on our Bugsquad. The work usually consists of marking it as a duplicate. The GNOME 2.16 crashers would reduce the workload by 1000 bugreports a week.
    Ideally, every bugreport would get special attention by the Bugsquad. Then they would receive the ‘bug was reported before, see that bug’. However, at a certain point you cannot support such things anymore. Also, I’d love if we’d have a Socorro server, etc, etc. But we don’t have it.
    So I understand what you mean, but it is just not practical.

    Lastly, this is not about backporting fixes. This is purely regarding Bugsquad and ensuring the members don’t go away because of the high voluntary workload. Whatever developers/maintainer do after that is up to them.

  7. I didn’t realize the dupe load was so bad. I thought the new features in bug buddy were reducing this significantly. Would it be possible to improve Bug Buddy to catch more of these?

  8. Brian: Bug-Buddy already blocks some reports (e.g. empty traces), and we also server-side block some crashers with a high number of duplicates (so called auto-reject feature in gnome bugzilla). also, ubuntu has started to report bugs by default against their own bug tracking system instead of gnome bugzilla for ubuntu 7.04.
    however, the number of bug reports has increased for the last two years by 80% each year, so we *have* to act, because this getting more and more. i triage a lot of reports and i can tell you that more than 90% of the 2.16 reports are duplicates.

Comments are closed.