...
- 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), you can use the moreinfo keyword to denote bugs awaiting 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.
...
| No Format |
|---|
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 (i.e. assigning it to yourself), 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
| Wiki Markup |
|---|
Generally in addition to using \[http://bugzilla.spamassassin.org/describekeywords.cgi Keywords\], we use the "Status Whiteboard" field to give a quick overview of what the status of the bug is. |
| Wiki Markup |
|---|
Bugs that need peer review are usually tagged with \[review\] in the subject as this makes it more obvious when reading the dev list that a bug needs review. This should maybe be a keyword also?*_Can somebody please explain the tags used in the subject line, I am aware of "RFE" and "\[review\]"_* (MalteStretz) |
Committing Fixes For Bugs
...
Categories For Closing Bugs
...
- FIXED: it's now fixed in SVN – this is usually used when a commiter checks in a fix for the bug.
- INVALID: it's not actually a bug report, or not something related to SpamAssassin – "SpamAssassin doesn't work!" or "I can't install SpamAssassin"
- WONTFIX: the report proposes something that we do not want to fix either for technical or philosophical reasons – "SpamAssassin should do anti-virus scanning"
- WORKSFORME: it's not reproducible, or the reported behaviour seems to be as designed
- LATER: this might be something we should look at in the far future, but for now its infeasible or undesirable – seldom used
- REMIND: we don't generally use this