GNOME Bugzilla upgraded to 4.4.

Dear GNOME community, you all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks: The Bugzilla software running on bugzilla.gnome.org has been upgraded to the latest stable version available.

• First of all: No amazing new custom features! But finally a maintained stable version of Bugzilla, without any larger customization regressions that I am aware of (smaller ones exist though, e.g. if your saved searches show zero results). After many years of being stuck with an old version.
  If you want to read about new features, check out the upstream Bugzilla release notes for versions 4.4, 4.2, 4.0, 3.6.
• Technical information about the setup and upgrade is available, and further technical background (an interesting read) on porting all those custom extensions of GNOME Bugzilla can be found in Krzesimir’s blog.
• Also see the many issues that got fixed by upgrading to 4.4 (either via custom patches or pulling from upstream) and are not mentioned below in this blogpost.
• Note that the default Bugzilla email format is now HTML. If you dislike that, change it to Plain Text in your General Preferences.
• If you have a “Can we have a nicer theme?” or “Can we install Bugzilla’s kitchensink extension?” type of question, the answer might be “Sure, if you plan to provide that code and maintain it”.

So much for the general information that I am aware of.

And some smaller stuff that I was into

I was confused that some people saw me as a point of contact for the Bugzilla upgrade, as I did nothing apart from testing, some smaller tweaks, and providing grumpy input and feedback. Though I admit that lately I have performed some smaller taxonomy changes unrelated to the actual migration though:

• Standardized the “latest dev code” Version field value in GNOME Bugzilla to “git master”
• Mass-fixed components that had no default QA contact set (which we use for notifications based on User Watching).
• Disabled the “Severity” field value “trivial” and moved open tickets with trivial severity to minor severity.
• Disabled random obsolete components in several products (now any product maintainers can do that!).

…and some smaller testing and simple tweaks in Bugzilla itself on its way to 4.4:

• Common links on the frontpage: “Reported by and assigned to me”, “Created in last 5 days”, “Changed in last 5 days”. Maybe more to come, let’s see (the frontpage still has too much unhelpful stuff).
  
• The Patch Report shows the author and size of patches now (bug 675822). Maybe you are more motivated to review a patch if it’s a small chunk and if it’s an unknown contributor, or one that you trust?
  
• The list of your patches on your user page now displays the summary of the bug report.
• Improved and added some stock answers for triagers.
• Gerrit IDs in comments now automatically link to the commit (thanks to a hacking session with Olav; bug 559537). Requirement: Your Git repository name needs to match your Bugzilla product name.
  

Vague personal future ideas for GNOME Bugzilla

• Best development practices:
  As I don’t see someone driving a discussion process to move GNOME to different (better?) infrastructure tools soon, I would like to make the custom “Browse product” and “Describe user” pages more useful for users to get an overview what’s there to work on and what is relevant (high priorities, new patches, target milestones) in a project. Many projects don’t really use Target Milestones or Priorities so far though I’m convinced it can be helpful if the tool properly supports you.
  Regarding practices, I’d also discourage setting a default human assignee instead of a virtual assignee for components so the list of assigned bugs per user is actually what you yourself really plan to work on.
  Furthermore, you probably do not want to set a default target milestone for the next version. It is just unrealistic and does not allow you to plan properly.
  All such stuff, you know.
• Maintainers can be encouraged to disable old versions and target milestones: Dropdown lists become shorter. (Though not too short because users might still want to report issues in older versions. You do not help reporters if you disable the version they use – they might still report their bug but just not set the Version correctly.)
  
• Remove the “URL”, “Tags”, “Hardware” fields in bug reports. Feature creep.
• Another area that welcomes improvement is avoiding cookie-licking. Your user page lists the tasks which are assigned to you. Do you realistically plan (means: rough timeframe and actionable steps identified, and not just some “would be good” feeling) to work on those tickets assigned to you? Also, your patches are listed there.
  Bugzilla also offers an overview list of open tasks per assignee (might load slowly) to see the full situation.
• A cronjob to dump taxomony changes into an email sent to Bugzilla maintainers as I am interested in consistency.
• Split the “docs” components of products into “User documentation” and “Developer documentation” components so it is easier for doc contributors to find tasks to work on. To discuss on d-d-l.
• Disable the “reviewed” patch status. It means nothing. Either a patch needs more work, or it is ready to go. To discuss on d-d-l.
• As the section heading says: Those are just ideas. They require discussion and time but you are very welcome to steal these ideas from me.

But what ever the future brings (or not):
You all owe Krzesimir Nowak, Andrea Veri, and Olav Vitters some icecream and drinks.