One week ago the GNOME Bugsquad had an IRC meeting initiated by Javier Jardón. The log can be found here.
To summarize the important decisions:
- Bug reports in GNOME Bugzilla (not: enhancement requests) with 1 year without any activity will be set to NEEDINFO state and reporters will be asked to update the report’s status by testing again on a recent GNOME version. After 6 weeks without response these reports can be closed as RESOLVED INCOMPLETE. A new stock answer will be made available for this.
- There are many modules in GNOME Bugzilla that have not seen any code changes for years (except for translation updates). Bugsquad members will try to identify those obsolete/unmaintained modules and contact the maintainers. We expect a response within four weeks from the maintainers. Without a response the remaining reports will probably be closed as WONTFIX while explaining to the reporter that the module is not maintained anymore and will not receive any updates. I must admit that I have done this already before and complaints were fairly low (2 people when I mass-closed open gnome-vfs enhancement requests) or non-existing (e.g. when closing all open Scaffold bugs).
- The “FIXED” stock answers will kindly ask bug reporters to verify the fix once it has landed in their distribution and if they have some time. The specific stock answers will be updated accordingly.
It was nice to discuss best practices and policies to have a less messy GNOME Bugzilla. Looking forward to our next meeting.
And PS: Hi to the Planet Fedora desktop readers.
Is there going to be a way to opt-out of the auto-closing? For Gnumeric
the process sounds like too much work and I believe we would much
rather take care of our own bugs.
Yes, sometimes it takes 5 years to fix something.
After these 6 weeks, can something be done about enhancement requests as well?
I’ve submitted a lot of bugs, and I have the feeling that the ones which were marked as enhancement are almost a poor-man’s WONTFIX. Nobody touches them, nobody comments on them, and poking the developers once every year (for the past 7 years!) doesn’t work.
Can there be some kind of review that will move old enhancements to WONTFIX or NORMAL priority?
@M Welinder: Definitely sounds worth to consider. Can you add that to the topics for the next meeting at http://live.gnome.org/Bugsquad/Meetings/ please?
@JustAGuy: Yeah, in Open Source resources are often limited – same for Developers and Bugsquad members.
A review for enhancements by the Bugsquad does not make sense I think. It’s up to maintainers to decide what to implement and what not, we cannot read their minds.
I think the auto-close policy it’s wrong, it’s destroying the work others have done, I mean, I have fixed several nautilus bugs that were from 2 to 4 years old, all were reproduceable and valid bugs, in some of them the reporter was not responding emails (it’s normal that in 2 years you change email address or you get interested in new things outside gnome, especially if in that 2 years you have received any feedback from the bug that you once filed..) . As an example the following bug was 7 years old, was a valid bug on those 7 years and possibly I could not find it and fix it if it was closed due to this policy.
http://bugzilla.gnome.org/show_bug.cgi?id=45588
In my opinion it’s nobody’s work to check if a bug is still valid (nor reporter, bug triaggers or developers) it’s work of whoever takes care and wants to do it, but should never be an excuse to close a bug that could still be valid.. so a developer can find it and fix it in the future.
@Nelson Benitez: You describe a valid negative side effect.
However comparing how many open reports are obsolete nowadays to the number of old untouched reports that are still valid I think it’s the right way to go. I’ve seen similar policies in Launchpad and Red Hat Bugzilla.
If a valid bug should not be closed then reporters or other folks should correctly update their reports (and the Version setting).
GNOME Bugzilla is not the trashcan where thousands of ancient bugs rot without being touched by anybody hence we do warn people before closing ancient tickets.
I guess when module is unmaintained the bugs should not be closed. Next mainterner (if any) may take care about them – unless modules is obsolete (such as gnome-vfs) and replaced.
There are some bugs that take years to fix, but you want to keep them around (they are real bugs). Does assigning new bugs as duplicates of this bug count as activity?
Perhaps a keyword could be used ‘keepopen’ or ‘hardfix’ or something.
Or maybe this should only apply to UNCONFIRMED bugs?
The Launchpad policy shits me to tears – their bug helpers are far more interested in stats obtained by closing bugs that actually helping users.
@Davyd: Yes, marking bugs as duplicates counts as activity.
Pingback: GNOME Bugsquad Meeting « muellis blog
@James: This is not entirely correct. We do not go closing bugs blindly (and, in fact, Ubuntu bugs do *not* expire). But we *do*, for bugs that have been opened for a long time, ask the reporter(s) if it is still an issue, and mostly on unconfirmed/incomplete bugs. Please also note that the bug status in Ubuntu do not completely match b.g.o.
And, BTW, my stats there are rather low ;-)