Introduction
Generally, we coordinate the overall flow on the SpamAssassin-Users and SpamAssassin-Dev MailingLists. Then, for specific new functionality or rules, a Bugzilla bug should be created to track progress and provide a forum for discussion; any patches should be stored (as an attachment) on that Bugzilla bug.
By using a Bugzilla bug to track code changes, we have an easy way to find the discussion/timeline of that functionality's development at any point in the future, since we can simply say "see bug 2134 for details/discussion/arguments" etc.
The code itself is maintained in a Subversion repository which can be browsed via the following methods:
General stuff
Patches and Coding
Rule Development
Infrastructure
- InfraNotes: notes on our infrastructure at the ASF and elsewhere, and adminning it
- InfraNotes2017: notes on our new ASF infrastucture
- RsyncConfig: How rsync is setup, how to add new accounts, etc.
- OpenInfraIssues: active bugs/requests we have open with the ASF infrastructure team
- MassCheckSlave: how to set up a new mass-check slave server
Stuff about scoring
More Stuff
- BayesStopList: information about the default Bayes "words to skip", and how they were chosen
- MailManglingInTheField: Information about known ways a mail message can be changed in transit.
- The SpamAsassin public corpus: an old collection of hand-filtered ham and spam for testing GA work, developing new filter techniques, and benchmarking filters.
- GTUBE: the Generic Test For Unsolicited Bulk Email.
- Package Building: RPM's, etc.
Historical information relating to the Incubation process
- IncubatorToDo: To-do list for moving out of the Apache Incubator
- ClaVettingProcess: How we tracked down code owners in order to relicense and the resolution of the process