Needinfo bugs

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

Likely almost all bugmail lost between 10:00 and 20:00 UTC

Very likely almost all bugmail has been lost between 10:00 and 20:00 UTC today (being July 11th). Due to a mailserver configuration error only people with a @gnome.org address could receive bugmail between this period. This includes new account emails, etc.

I made a quick query to show the 202 new and changed bugs between this period:
this query

Note that this query uses the last changed date. So as soon as the bug is changed again it will disappear from this list (this is on purpose).

Update: Whoops! Used the wrong month in the query

TARBALLS DUE: GNOME 2.15.4 Development Release

Tarballs are due on Monday July 10th (this Monday) before 23:59 UTC for the GNOME 2.15.4 Development Release, which will be delivered on
Wednesday. If for some reason you are not able to make a tarball before Monday, please send a mail to the release team: they can find someone to roll the tarball for you!

After July 10th the following announcement periods begin:

  • String Change Announcement: All string changes must be announced to both gnome-i18n@ and gnome-doc-list@.
  • UI Change Announcement Period: All user interface changes must be
    announced to gnome-doc-list@.

Modules which were proposed for inclusion should try to follow the 2.15 schedule so everyone can test them.

For more informations about 2.15, the full schedule and the official
module lists, please see our shiny 2.15 page on the wiki:

http://live.gnome.org/TwoPointFifteen

To help write good release notes, please add major user-visible changes
happening during the 2.15 release cycle to this wiki page:

http://live.gnome.org/TwoPointFifteen/ReleaseNotes

Usually these announcements go to devel-announce-list and gnome-hackers, but as I still haven’t seen the email pop up after 9 hours…

Bugzilla will be DOWN Friday 7 July 2006 21:00 UTC

Bugzilla will move to a different server on Friday 7 July at 21:00 UTC. If you want to know what time that is for your location, look here. The move should not take more than 30 minutes, including DNS update (refresh time has already been shortened to prepare for the move). For those with broken DNS servers I will announce another name here + on the old server to reach bugzilla.gnome.org after the move has been completed (it will not work reliably before everything has been moved over).

I am now an upstream Bugzilla developer. Checking their Getting CVS Write Access feels a bit overwhelming. Getting GNOME CVS access was much easier (ok, I just dislike the faxing part).