Much ado about scripting, Linux & Eclipse: card subject to change


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


AlBlue said...

It doesn't render properly in Safari, either -- there's a bug open for that. Might be the same one, or rely on some dodgy Firefoxy-XSLT or something (or a completely different one). I mention this merely for information ...

> perhaps the underlying problem is that we
> as committers need to better educate the
> community on how to find bugs and track
> their progress
> And it's in ONE common language, all
> focused aroung ONE community. So what if
> we use that language a little differently?

The main problem is confusion. Confusion and frustration. The two main problems are confusion, frustration, and a fanatical devotion to the ... I'll come in again.

The main problem is that in the wider open-source world, Bugzilla is frequently used (and understood). REMIND and LATER are both artifacts of an age gone by, and the open-source community generally has already deemed these not to be valid states; you don't get them in new (or most existing) installs. There already is a common language; and it's used in the same way across many, many open-source projects. Eclipse is just different, and it's just different for no (particularly) good reason or indeed, benefit.

There is an associated problem. You guys are looking at this from the inside. The community only gets to see it from the outside. When someone files a bug that their Editor barfs when it hits a component on an EFS system and draws cheese, it could be any one of five or six teams that are 'responsible' for that bug (obviously, depending on where it happened). A similar bug may be raised by the same person, but then get addressed by a different team. As far as the user is concerned, they've submitted two bugs against Eclipse. Why should they be handled or represented differently, just because it's a different team handling the bug? Indeed, what if every team used it in a different way? Words like 'RESOLVED' would completely lose their meaning if each team could re-define it to mean what they wanted.

The point is this; having one common language is not enough; you also need everyone to use it in the same way. End users see Eclipse, the product; not Eclipse, the collection of plugins that are developed by different people and just happen to work together. The bug database shouldn't reflect those internal policies either.

nickb said...

(Yes, it's most likely using browser-based XSLT, which KHTML doesn't play nicely with (Konq/Safari).)

> The main problem is confusion. Confusion and frustration.

Damn, I'm forced to agree with you again, and not just for pulling out the Python reference. ;-P

But despite the fact that everyone working the same way and presenting one common method is A Really Good Idea, in practice it can't happen overnight. Trust me, I've been there, tried that.

Question... does everyone at Sourceforge track bugs the same way? Do you expect them to? And if not, why not? Why is Eclipse seen as One Single Family but other OSS communities seen as a divergent set of teams all working in the same general direction, but with divergent needs & processes?

What about in Linux kernel land? Or KDE? Or Mozilla? Is every community so homogenized? Is it really just Eclipse that's the black sheep here?

Anyway, while some people are clearly not thrilled w/ the status quo, I think the one major benefit to come out of this dialogue is that. Dialogue. Discussion. And perhaps over time, change, growth, and understanding.

In the meantime, I won't use LATER unless I really mean it. And I'll watch my bugs (and those I've opened) with Gmail. That way I don't care what arbitrary resolution is but on my bugs - I can always reopen 'em if they've sat idle for too long (and I do).

AlBlue said...

> Question... does everyone at
> Sourceforge track bugs the same
> way? Do you expect them to? And if
> not, why not? Why is Eclipse seen
> as One Single Family but other OSS
> communities seen as a divergent set
> of teams all working in the same
> general direction, but with
> divergent needs & processes?

Your question belies your assumption that Every Team Does It Differently. That isn't the case. I don't really care how other OSS communities make their plans or figure out what they're going to do in the morning, but I do expect a RESOLVED bug to be RESOLVED, and a NEW bug to be NEW. In fact, any OSS community using any bug tracking system would do this.

The point is, it doesn't matter whether it's hosted on Apache, SourceForge or Eclipse -- I expect *all* bug tracking systems to be used to track bugs. There are well-defined states for these things, and everyone (pretty much *except* Eclipse projects) use them in the same way.

There is a tangential question -- how committers on those projects plan their work, figure out which bugs get scheduled for release X rather than release Y. To be honest, I'd expect variation in that process; which will be different depending on size of team, amount of time available to work etc.

But regardless of the *process* used, Bugzilla -- Jira, whatever -- should use the bug states to actually represent bug states, and not plan-of-work items. It is *only* Eclipse who gets this wrong, and even then, only some projects inside Eclipse.

There are other ways of tracking planning info -- release milestone, target milestone etc. which can be used to do these things, but 'resolution state' is not one of them.