Category: General

Bugzilla has long had some etiquette rules; though they haven’t really been set in stone or enforced very uniformly[1]. We think the Code of Conduct embodies these rules well and will be making them more noticable from bugzilla (when a Bugzilla user creates an account, a link on the front page, etc.). As a result I’m going to remove the “this is a draft” comment on the page and say it applies to GNOME Bugzilla.

Also worth noting is a recent incident where a maintainer was
repeatedly insulted by a user both in bugzilla and private email (and
IRC and on various mailing lists) — and even continued to do so after being warned to stop. We eventually found out and disabled the
account, but there was really no reason to let the problem last so
long. If you[2] experience a similar problem, let us know[3].

Thanks,
Your friendly GNOME bugmasters

[1] Though we have sometimes pointed people at
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.

[2] “You” being a GNOME user, developer, bugmaster, etc.

[3] Depending on the situation, we can just add an extra warning in the bug, temporarily disable the account (meaning until they contact bugmaster@ and agree to change their behavior), or permanently disable in extreme cases.

[4] Yes, this started out as an email.

Please abide by it. It is pretty easy to follow actually. It disallows *all* robots from accessing bugzilla.gnome.org. If I find out that you have been performing robot-like behavior on GNOME Bugzilla you will be blocked. This is needed to ensure the speed stays somewhat ok.

So if for example you write some app that downloads 9000+ bugs individually via XML, ask bugmaster@gnome.org first. There are usually far better (and often faster) ways to do the things you want if you just ask. I can understand spammers not following this rule (those are pretty easy to spot.. do things any sane client would/could never do), but when it is an IP address from Sun I wonder… same for people using a recursive wget to download everything from GNOME Bugzilla (wget’ing a patch is of course ok).

Anyway.. mail bugmaster@gnome.org and explain yourself if your IP address was one of the lucky ones to be blocked from Bugzilla this week. Disable the robot-like software before asking though. Oh, stuff like IRC bots that lookup bug numbers are of course ok (as they generate only a few lookups/day). When in doubt, ask.

I finally discovered why Bugzilla is sometimes so slow (meaning: not responding for a few minutes). I used to blame it fully on table locking (Bugzilla needs MyISAM for full text indexing). My solution would be to setup replication (avoiding some of the locking). Today I finally discovered that it was actually due to people searching for all bugs they commented upon… exactly the same query I added recently to describeuser.cgi or ‘My Bugs and Patches’ (didn’t notice the query being so slow when I added it).

Initially I removed the query from describeuser.cgi and I changed the apache config to redirect these queries to a page explaining it was slowing down Bugzilla too much. After that I asked in the Bugzilla developers channel if this was fixed after 2.20. Mkanat looked into the problem and the ‘EXPLAIN SELECT‘ + query. He discovered MySQL was using the wrong index. I made MySQL forcefully use the right index. This sped up the query, but it still was slow. A few minutes later mkanat had a patch ready. Testing it gave great results. Initial query ran in 4 minutes, 30 seconds. My ‘force index’ did it in 27 secs. The fix by mkanat made it run in 1 second! This fix will be in the next Bugzilla version (probably 3.0) and on bugzilla.gnome.org. The fix is pretty easy to port to 2.20 although it will not apply cleanly; see bug 57350 if you want the patch.

Anyway, thanks mkanat!

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

As announced a while ago GNOME will switch to Subversion starting TODAY at 23:59 UTC. See http://live.gnome.org/Subversion and a FAQ at http://live.gnome.org/SubversionFAQ. I actually forgot it was today already, so I’m guessing others did as well.

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 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 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).

The software behind blogs.gnome.org (NewsBruiser) has an interesting default. By default the feeds only give the entries for the current month. So if you make a post minutes before a month ends, likely no planet will show your post.

I couldn’t really understand how I could fix this safely (without breaking other stuff), so I’ve added a hack instead. The feeds from blogs.gnome.org will now always show the last 15 entries. There is some code in there so you can get a feed specific for a year. This is probably broken now.

I checked the server logs and nobody seems to be using anything but the standard syndication URL, so above hack shouldn’t cause any problems. If you find your feed is broken, please file a bug. And please post a patch as well 😉

A few more patches I made for Bugzilla (official one, not b.g.o) have been accepted. Bugzilla 2.24 (or the not-yet-released 2.23.2) will now have a preference to control the initial state of the ‘Add me to the CC-list’ checkbox. By default it is checked unless you have a role (reporter/assignee/qa contact) on the bug.

An important patch is one that detects if the user is trying to submit the same bug multiple times. This could happen if a user refreshes the post_bug.cgi page. Due to some dynamic content on the post_bug.cgi the obvious fix (redirect to show_bug.cgi) could not be done. The patch will give a warning when the users tries to submit the same bug again (for more details, read the bugreport).

Another one that was accepted a while ago adds a X-Bugzilla-Watch-Reason. It changes the existing X-Bugzilla-Reason header to only contain the reasons why you are on a bug (Assignee, Reporter, etc). If you are only watching people on a bug, X-Bugzilla-Reason will contain None (handy for filtering). The X-Bugzilla-Watch-Reason will contain None if you are not watching anyone on the bug. If you are watching someone it will contain the reasons and also the email addresses you are watching. I plan to merge this patch into bugzilla.gnome.org soon (currently we do differ between being a role and watching a role, but it all ends up in X-Bugzilla-Reason).

LpSolit (Bugzilla developer) is currently working on moving the CheckCanChangeField function from process_bug.cgi to Bugzilla/Bug.pm. This function checks if the current user is allowed to change a field (priority/version/summary/etc). When this is done I’m going to change the show_bug.cgi template to use this function and only allow the user to change the fields they are allowed to change. The end result will be like on bugzilla.gnome.org, except on b.g.o I hard-coded the permissions in show_bug.cgi, while the upstream version will use the same function for the UI as well as the backend.

When Bug-Buddy starts it will check if it needs to update its configuration files. It does this maximum once per day by checking the time of three XML files on bugzilla.gnome.org.

From the bugzilla.gnome.org webservers logs I grepped the hits to one of these files. Each hit will contain the gnome-vfs version that was used to access it. A pretty safe assumption is that the gnome-vfs version is the same as the GNOME version.

Per GNOME (gnome-vfs) version I now have the number of hits generated during a month of data. Again, Bug-Buddy only checks once a day and the hit is only done when someone starts Bug-buddy (eg app crashes and you click the ‘Inform Developers’ button).