You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Opening Bugs For Development

The general practise is to open a bug when some task needs to be done, even if there is no "bug" involved. The idea is to provide a "thread" of discussion and a place to track development. Also does Bugzilla offer a more persistent way of storing things, ie. stuff like patches and votes are less likely to get lost on the mailinglist.

Current Milestones

  • 3.1.0: next major release (also see ReleaseGoals)
  • 3.1.1: next minor release (bug fixes and minor things that we'd like to get fixed, but don't want to hold up 3.1.0 for them)
  • 3.2.0: next major release
  • Undefined: no milestone set
  • Future: maybe at some point in the distant future

Bug Triage

Here is how you handle bug triage:

  • mark duplicated bugs as duplicate
  • try to confirm bugs
  • test submitted rules with promise (see AutoMassChecks)
  • ask users for additional information as needed (sooner is better if you want a response)
  • set the severity (how bad does it affect things, is it an enhancement request, etc.)
  • close bugs already fixed (when possible, this is mostly done by developers, but sometimes it's obvious or easy to tell)
  • close bugs that are invalid.
  • if you can reproduce a bug under the current svn, update the Version flag if not already set to svn.
  • when any of the above is being done, and you're not yet ready to set a milestone or close a bug, then flag the bug with a keyword "triage". This will indicate to other triagers that the bug is already undergoing triage.

That leaves priority and milestone setting...

Priority doesn't really get used much and is in theory set by the assignee, so let's ignore it.

We do use the milestones a lot. Developers are always going to tweak those, but I think we could come up with a procedure to allow those to be set fairly accurately in a first pass triage. Something like:

   if (bug)
      set severity appropriately if needed
      if (bug affecting current svn head)
         assign to next release off of svn head
      elsif (bug affecting current stable release)
         if (bug affects both svn head and current stable)
            # I'm still not entirely happy with how we handle this case...
            assign to next release off of svn head, make note in bug
         else
            assign to next stable release

   else
      set severity to "enhancement"
      if (pie-in-the-sky)
         assign to "Future"
      else
         assign to next major release

When Taking Bugs...

MichaelParker phrased it like this:
When taking a bug in Bugzilla, please go ahead and make sure
dev@spamassassin.apache.org is in the CC list. That way bug
discussion is out in the open.

Tagging Bugs

Can somebody please explain the tags used in the subject line, I am aware of "RFE" and "[review]" (MalteStretz)

Committing Fixes For Bugs

When you commit a fix for some bug, the number of the bug should be stated in the commit message. JustinMason said once:
BTW, a tip on referring to bugs – the convention is

bug NNNN: blah blah

simply because Bugzilla has the smarts to automatically turn "bug NNNN"
into a hyperlink – and it's easily greppable.

  • No labels