• Bugzilla

Bugzilla is a widely-used bug tracking system. People either seem to love it or hate it. Let's try to be specific about its pros and cons, though:

Pros and Cons

• pro: widely-used, so many people are familiar with it
• pro: ability for people to sign up to watch PRs (be notified by email when they change)
• pro: ability for users to vote on which PRs are the most important
• pro: automatic assignment of "responsible"
• pro: separate status and resolution (i.e. [verified, duplicate bug #x])
• pro: attachments
• pro: keywords
• pro: understands code branches
• pro: submission of a problem via the webinterface requires a login with a verified email address.
• pro: security/ACL features that allow e.g. the Security Team to use the main bugzilla to track issues without allowing non-Security Team users to view the bugs.
• con: requires porting the PR database over. Ceri tried this and reported that it was hard (due more to the random nature of our PRs). Edwin tried it and came up with some nice output.
• con: some people feel that the user interface is cluttered

  • This should not be an issue since user interface Template Toolkit (http://www.template-toolkit.org) based therefore may be customized exactly the way it looks like atm.

• con: does not run under mod_perl, thus performance is impacted? ( SOLVED: see http://www.bugzilla.org/features/#mod_perl)

Issues that need investigation

• no exact replacement for send-pr?
  • This can be done via a conversion script
• how much work would it take to do the database replication if users still want that?
  • Tests done by Edwin show that it is possible very easy for the big chunk, but the audit-trail is also imported with the main body.
• is it secure enough? (we have to have troll-proofing)
  • given that the troll is human, can anyone conceive of a system that would keep a troll out?
• there is no 1:1 class mapping into bugzilla scheme. some decision must be done how to handle this (ie. map to keyword)

Backend

• Bugzilla can run on MySQL, PostgreSQL and Oracle. It's also possible to write a driver for the database of your choice.

References

• http://www.bugzilla.org

• improved database conversion script used during tests: freefall:/home/edwin/gnats/gnats2bz.pl

Developer comments on Bugzilla

Please place your personal opinions on bugzilla here. Since many efforts to look at moving us away from GNATS have focused on bugzilla, we should know if it has major usability issues.

anholt

I routinely use bugzilla for freedesktop projects. I find I'm more productive, and search for PRs besides those assigned to me more often. I've also been mostly impressed by the process for flagging patches, which has been used effectively for the X.Org 7.0 release process.

I find GNATS useless because it lacks separating attachments from comments (Most PRs I deal with have at least one 500+-line Xorg.0.log, or should), lacks CCing interested users (so I have to go find the list of releveant folks by hand and feed it into my gnats followup To: line), having to ssh to freefall to edit PRs (and use a crappy text editor), having to have FreeBSD booted to run send-pr to submit PRs, and lack user control (so they can't close their report if they decide it's not an issue). Bugzilla covers every one of these issues to my satisfaction.

My gripes with bugzilla:

• Lack of "state -> ASSIGNED, reponsible -> anholt@FreeBSD.org" button. So that becomes two steps. I hear this is a quick fix in bz code.

• Lack of "attach patch immediately with report submission". So that becomes two steps: submit report describing problem, then attach the patch afterwards.
• gerald 2009-01-02: as seen at bugzilla.novell.com, current versions of Bugzilla support the above!
• Lack of (or hiddenness of) ability to edit any part of a bug report by bugzilla superusers. Sometimes I want to nuke comments that are just noise, or slip an inline log into an attachment.

gerald

I have been using both GNATS and Bugzilla for many years, and quite a lot, and find that GNATS lacks so much in terms of basic functionality like Cc:ing myself or others, supporting attachments, ability for non-committers to do anything in addition to submitting and adding comments,... that I strongly support switching.

arundel

i've talked to a few of the freebsd-clang developers, because they interact quite a lot with bugzilla (http://llvm.org/bugs). they are quite happy with the way bugzilla works. in contrast to that, i've asked them what their opinion of the current freebsd bug tracking system is atm. they reported that after using GNATS once or twice they have decided to completely avoid it. they told me that almost every freebsd developer they know of is trying to stay away from our current problem report database, because it is much to complicated and simply not state of the art. also none of the freebsd-clang developers is missing the ability to access the clang/llvm bugzilla database from their shell via a script similar to send-pr(1). most of the younger freebsd developers don't care about that at all and would gladly sacrifce the shell scripts, if they could finally get a decent problem report database to interact with. while bugzilla defenately has some issues, imo it's the best choice. it's being widely used by other major open source projects and a lot of freebsd developers are thus familiar with it. also keep in mind that moving onto a new bug management system will not be the end of the story. it might become obsolete (like GNATS) and freebsd has to move onto yet another system. with bugzilla we could rely on the fact that a lot of other projects are facing the same task and coming up with a plan to move to a new bug management system can be shared between several open source projects. switching to a bug management system, which isn't widely used might mean that the task of writing scripts etc. to switch to yet another bug management system rests alone with freebsd. and judging from the current situation freebsd does not have the capacity to face this task! imo the decision, which bug tracking system freebsd should use should not rest alone with the bugbusting folks. a new bug tracking system should meet the needs of the majority of the freebsd developers. we need a bug tracking system which attracts the majority of the developers. what we don't need is a system which wins by design criterias, but scares off freebsd developers (and users) yet again. so my recomendation is to cast a vote in which all freebsd developers can participate. step 1) should be a gathering of possible bug tracking systems. step 2) should be the actual vote. the actual details (e.g. which version of bugzilla to use) should then rest with the bugbusting folks.

n.b.: with my comment i wasn't trying to criticise anybody at all. i'm sorry, if people have been offended by it. actually what i tried to say was: the wishes of the community are more important than any technical aspects. i wasn't concluding that this is the current practise.