[Spamassassin Wiki] Update of "UsingBugzilla" by JustinMason

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.

The following page has been changed by JustinMason:
http://wiki.apache.org/spamassassin/UsingBugzilla

The comment on the change is:
add some more notes

------------------------------------------------------------------------------
  == 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.
+ The general practise is to open a bug when some task needs to be done, even if there is no "bug" involved; it's really a "task tracker", not a "bug tracker".  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.
+ 
+ That way, when a developer is later reading the code, and wondering why a certain database design is used (for example), they can look up a bug number referenced in a comment, and see the entire discussion thread for that design decision.
+ 
+ BTW, this is different from other ASF projects, who prefer discussion on mailing lists and bugs on the bugzilla.  That's OK, we're different!
+ 
+ Bugzilla also offers a more persistent way of storing things like patches and votes; these are less likely to get lost than they would be if they were posted on the mailing lists.   Plugins that are likely to be frequently downloaded by third parties and users, should probably go on the wiki -- e.g. the CustomPlugins page -- but stuff that is intended for inclusion in the main distro, Bugzilla is best.
  
  == Current Milestones ==
+ 
+ ''(consider this an example of how the milestones are used, assuming that in this example we are somewhere between the 3.0.x and 3.1.0 releases.  there's no need to update this example for every future release...)''
  
   * 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)
@@ -20, +27 @@

   * 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
+  * 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.
  
- That leaves priority and milestone setting...
+ Severity describes the impact of the bug, and is often set by the
+ submitter.  The only really important value here is 'blocker' or
+ 'critical', both of which indicate that the bug should block further
+ releases until it's fixed.  
  
- Priority doesn't really get used much and is in theory set by the
- assignee, so let's ignore it.
+ If the developer doesn't agree with the Sev setting, they can go ahead and
+ change it -- but it doesn't really matter anyway, since the Priority is what
+ actually affects the operation of Bugzilla (sort order etc.). ;) In theory, the
+ developer working on the bug can use Priority to indicate how important
+ __they__ think the bug is.    In practice, we don't use it much.
  
  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
@@ -56, +69 @@

           assign to next major release
  }}}
  
+ Requests for new features should have a Sev of 'enhancement', and optionally have a title beginning with 'RFE:'.
+ 
  == When Taking Bugs... ==
  
  When taking a bug in Bugzilla (i.e. assigning it to yourself), please go ahead and make sure
@@ -68, +83 @@

  
  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?
  
+ Nah, leave it a subject tag, since that appears in mail. no need to have it twice! -- JustinMason
+ 
+ We also use 'needs N votes' in the Status Whiteboard field.  However, as far as I can see whenever we're in a situation that votes are needed, the voting population are never reading this anyway, so I think it may be superfluous. ;) -- JustinMason
+ 
  == 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:
+ When you commit a fix for some bug, the number of the bug should be stated in the commit message.
-   BTW, a tip on referring to bugs -- the convention is
  
-         bug NNNN: blah blah
+ JustinMason: 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.
  
-   simply because Bugzilla has the smarts to automatically turn "bug NNNN"
-   into a hyperlink -- and it's easily greppable.
+ JustinMason: also 'bug NNNN comment NN' gets turned into a hyperlink
+ to a comment.
  
  == Categories For Closing Bugs ==