Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added section aimed at end users

Opening Bugs As A SpamAssassin User

Please do not open bug reports for issues that you are not prepared to demonstrate as being a bug in SpamAssassin OR in the case of enhancement requests, define clearly and defend with evidence. Some points to consider:

  • In general, "false positive" spam filtering incidents by one or more specific sites are not actionable as bugs in SpamAssassin. These issues are best addressed on the SpamAssassin Users  MailingList where a broad audience of SpamAssassin users can analyze the root causes and advise on solutions (which may include opening a valid bug, but likely will not.) 
  • It is extremely unlikely that a problem with any major mailbox provider (Gmail, Microsoft, GMX, Yahoo, etc.) delivering legitimate mail to a "Spam Folder" is in any way related to SpamAssassin. It is absolutely certain that such issues cannot be addressed by a SpamAssassin bug report. Large mail service providers generally use their own proprietary spam filters, NOT SpamAssassin. 
  • If you do not have a basically working SpamAssassin installation with which you can reproduce the issue and include evidence in your bug report of a bug in SpamAssassin, your bug report is likely to be closed as WORKSFORME or INVALID. Someone else's SpamAssassin installation accessible only through a web page that lets you "check your mail with SpamAssassin" is very likely to not suffice, as such sites frequently run outdated rulesets or even outdated SpamAssassin core code. 
  • Bugzilla is not a general SpamAssassin tech support channel. When in doubt about whether your issue belongs in Bugzilla, use the SpamAssassin Users  MailingList. More eyes see messages there and the general user community is familiar with more diverse use cases than the SpamAssassin developers who see bug reports. The overwhelming majority of problems with SpamAssassin are not bugs per se, but rather errors in adapting SpamAssassin to special local circumstances.
  • For enhancement requests, code contributions are usually helpful but are not strictly necessary. It is necessary to understand that SpamAssassin has a consciously constrained scope as a scoring tool for mail messages. It is not a mail handling agent of any sort and so does not deliver, block, or discard mail. It does not analyze any data format that is not at least approximately conformant to RFCs 822, 2822, and 5322 and their MIME extensions, e.g. individual mail messages and parseable mailbox formats. 

Opening Bugs For Development

The general practice 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.

...

(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)
  • 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), 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.

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.

...

Generally in addition to using 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?


Nah, leave it a subject tag, since that appears in mail. no need to have it twice! – JustinMason

...

  • 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

Removing Spam Bugs

Deleting a bug that is spam can only be done by someone who has Administrator access to our Bugzilla. See RemovingBugzillaSpam.