Desperately Seeking Status (Of My Bugs)

Since being syndicated at PlanetEclipse a few short hours ago, I've already incurred my first response from Alex Blewitt, of bug 178923 fame. Thanks Alex! I feel like I'm finally part of the Eclipse blogosphere. [Incidentally, PlanetEclipse (since its facelift at EclipseCon) doesn't render in Konqueror. I'd open a bug about that, but then I'd have to close it myself as WONTFIX or WORKSFORME because it works just fine as a Google homepage widget in Konqueror. But I digress...]

Kidding aside, I'd like to address your comments here in a fresh entry. Note that much of what I'm saying below is in reference to the general J. Disgruntled-Eclipse-Commmunity-Member, not Alex Blewitt personally. ;-)

It's not about 'never fixing bugs' or for that matter 'not able to reproduce' bugs. It's about hiding bugs so that you can't search for them by virtue of them being in the RESOLVED bucket.

Since there's a lot of different ways to manage a project using Bugzilla, and many different ways to mark status of bugs (other than simply their state being NEW, ASSIGNED, or FIXED)... perhaps the underlying problem is that we as committers need to better educate the community on how to find bugs and track their progress, plus how we use Bugzilla to track our own progress.

For the sake of leading by example, here's what *I* do:

1. Configure Bugzilla to send me emails for almost everything that happens in bugs I care about. Bugs I care about include: ones I've opened, ones assigned to me, ones for which I'm cc'd, and ones that depend or block any of the above.
2. Since I work for IBM, I use my IBM email address as my Bugzilla address; however, I've received the nod from On High that it's okay (since it's all in the public domain anyway) to have this mail forwarded to my Gmail address.
3. Because Gmail rocks for sorting, searching, and filtering, I have it configured to automatically label all Bugzilla emails with a special label, and skip my inbox.
4. This keeps my inbox clutter-free, but also lets me watch the left side of my Gmail screen for when there's bugs I need to read (that is, unless I've read them in Eclipse thx to Mylar!)
5. To be notified when there's something new in a bug I'm watching, I've installed the .deb package 'gmail-notify'. If you're on Windows, there's Gmail Notifier instead.
6. Regardless of a bug's status, I can now query Gmail to find the bug I care about, including posted comments and links to attachments. I don't even need bugzilla itself (though I still use that for other searches).
7. To track a subset of bugs I care about (my immediate TODOs), I have set up canned queries (do a query and then save it for future reuse) which work both in a browser and in Mylar, too. If you love Mylar like I do, you probably already know this; if you don't just add a Task List view > New > Query... using the "Create query from existing URL" option, like https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=My%20TODOs and you'll see what Bugzilla sees, in Eclipse. Just make sure you Task Repositories View > Add Task Repository with your committer id/password or you won't be able to retrieve the canned query from your Bugzilla profile. pserver:anonymous is faster, but not as powerful. If you're not signed up as a Bugzilla user, do it today, so you can tweak your email settings and configure canned queries!
8. There's no special magic for finding bugs you care about. It's just a matter of playing with Bugzilla's Advanced Search until you get what you want. I find more often than not, the best approach is to use only a few simple restrictions - too many and you'll get the ever-annoying (but amusing) Zarro Boogs.

On the topic of how I use Bugzilla to track my own progress, I admit this is a bit of a hack... but it works. In EMF-land (and those (un)fortunate? enough to have been assimilated into our workflow), we use, generally, three bug states:

1. NEW: bug is open and/or being worked. Comments will appear in the bug as it progresses. Note that not all bugs are bugs - many are enhancements, feature requests, or plan items / placeholders. Some are duplicate markers so that we can close the same bug in multiple streams and generate accurate releaes notes from those changes.
2. ASSIGNED - fix is in CVS, awaiting the next build to be released. Sometimes ASSIGNED also means we're playing 'pass the bug around' because there's parts that need to be worked by multiple people. Release Engineering bugs are notorious for this because I tend to open single bugs for umpteen work items, and because my works depends on others' and vice versa, so we can assign bugs back and forth as needed. I like this feature too because when I assign a bug I'm working to someone else, it disappears from my "TODOs" query until it's bounce back to me.
3. FIXED - fix is availabe in the latest build. Thanks to a bit of code written by Neil Skrypuch, my fantastic co-op student from this past summer/fall, we have a tool (and it's in org.eclipse.releng.basebuilder!) which you can use to automatically move ASSIGNED bugs to FIXED when releasing a new build.

Also, it's not LATER and WONTFIX as your blog post suggests -- it's LATER and REMIND. I don't think anyone has an issue with WONTFIX or WORKSFORME if they're valid resolutions.

On occasion, these states are used too, skipping from NEW to FIXED. I agree it's a bit of a misnomer to say a bug you opened that will never be fixed (WONTFIX) or that might be fixed some day in the far-flung future (LATER) is "FIXED", but that's the way the tool works. If you distance yourself from the dictionary definition of the word and instead use it in the context of Bugzilla, it really just means 'not being worked anymore' - for various reasons. I'd like to see a COMMITTED and a RELEASED state be added, but we can't all get what we want, and so we work around these sorts of situations the best we can with the time, tools, and resources we have.

I'm not going to get into the religious war about bugs states that bug 178923 has become. Let me just conclude this diatribe by suggesting that Bugzilla is a database. With a lot of data. Managed by a lot of diverse groups, in diverse places, with diverse work styles, on diverse teams, from diverse companies, universities and parents' basements. Despite all that diversity, we have a system in place that can cope with the 100s of requests logged every week. And it's in ONE common language, all focused aroung ONE community. So what if we use that language a little differently?

I welcome your comments & thoughts.