I’m trying to make Bugzilla not bother developers about the bugs that are not important (or having to follow every bugmail closely). One example is the needinfo bugs. As long as a bug is in the needinfo state, you should not be bothered with it.
Hiding these needinfo bugs caused a few problems:
- Reporters didn’t reopen needinfo bugs
Logically, reporters should not have to know that needinfo bugs should be reopened if the requested information has been given. However, this wasn’t made clear. Elijah changed GNOME Bugzilla a while ago so that anyone changing a needinfo bug will be asked if they provided the requested information. When answering yes, the bug will be reopened. - Needinfo bugs being forgotten
Sometimes bugs can be fixed faster/easier when the reporter provides extra information, but with extra work the developer could fix it. If a developer doesn’t notice needinfo bugs anymore, that extra work will never happen.
Bugsquad triaged 1439 needinfo bugs that haven’t been changed in over 3 months. In less than a week around 1100 bugs where closed as incomplete or ‘reopened’. An old copy of the weekly bug summary shows just how many bugs have been closed (copy of the top 15 bug closers for 7 days):
| Position | Who | Number of bugs closed |
|---|---|---|
| 1 | Andre Klapper | 399 |
| 2 | Olav Vitters | 314 |
| 3 | Baptiste Mille-Mathias | 114 |
| 4 | Karsten Bräckelmann | 87 |
| 5 | Charles Kerr | 37 |
| 6 | Fabio Bonelli | 35 |
| 7 | Christian Kirbach | 35 |
| 8 | sven gimp org | 16 |
| 9 | Matthias Clasen | 15 |
| 10 | Aaron Bockover | 15 |
| 11 | David Trowbridge | 14 |
| 12 | Brent Smith (smitten) | 12 |
| 13 | Gustavo Carneiro | 12 |
| 14 | Tim-Philipp Müller | 12 |
| 15 | Victor Osadci (Vic) | 11 |
To avoid these needinfo bugs being forgotten in future, I’ve added a needinfo overview to browse.cgi which shows per last changed period the number of needinfo bugs. This way you can easily see the number of needinfo bugs changed in the last 2 weeks, or how many haven’t been changed in over a year. It still needs a bit of UI work to clearly show that this overview is the only part where needinfo bugs are shown. I actually made this patch a week ago, but I had to fight with SELinux to make changed files be shown by Apache. Not knowing anything about SELinux a week ago solving this took a bit of time. It seems to work now, although I do not understand why at first it didn’t and now it does. It seems to me that initially patch and cp in a directory changed the security context and suddently it does not. Oh well.
Debugging symbols
Usually bugs are marked needinfo because the stacktrace is not good enough. I would be very happen if someone either:
- Figured out a way to make bug-buddy ask for and automatically download+install the debugging symbols for some of the distributions. It does not have to work for all distros. Just one ‘major’ distro would be enough. Want to solve this? See bug 331004.
- Figure out a way to have a few common distros installed in a chroot on a server, make bug-buddy send the core file (or whatever) to that server, then generate the stacktrace with the debugging symbols and make a bugreport for it. Hopefully after checking for duplicates first 😉
- Change http://live.gnome.org/GettingTraces to be more understandable for the someone who only noticed some dialog popping up asking for their email address (meaning bug-buddy).
I hate marking these bad stacktraces as needinfo or closing them as incomplete. I fully understand 99.9%+ of the users not understanding what we want from them when given the GettingTraces link. Some distributions not even have debugging symbols for all packages, making it even worse. I hope this problem can be resolved by one or more persons looking at the relevant bug-buddy bug: bug 331004. Another way would be providing GNOME packages (rpms/debs) as part of the Build Brigade.
Bug aliases
A while ago somebody discovered bug aliases. Using this field you can give a name to a bug. When duping, marking depends/blocking another bug instead of entering the bug number, you can just fill in the bug alias. It also works for show_bug.cgi. Loading http://bugzilla.gnome.org/show_bug.cgi?id=gtkbuilder will show bug 172535. I received a request if I could make http://bugs.gnome.org/gtkbuilder redirect to http://bugzilla.gnome.org/show_bug.cgi?id=gtkbuilder as well. I did that this weekend and made it work for both bugzilla.gnome.org as well as bugs.gnome.org. The bug alias must match ^[A-Za-z0-9]+$ for this to work.
And best for last: I joined the GNOME sysadmin team