You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spamassassin.apache.org by Apache Wiki <wi...@apache.org> on 2011/09/13 21:43:16 UTC
[Spamassassin Wiki] Update of "ReleaseGoals" by KevinMcGrail
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Spamassassin Wiki" for change notification.
The "ReleaseGoals" page has been changed by KevinMcGrail:
http://wiki.apache.org/spamassassin/ReleaseGoals?action=diff&rev1=11&rev2=12
Comment:
Clean up of the release schedule, support and goals
- ## page was renamed from 3.2PrevReleaseGoals
- ## page was renamed from ReleaseGoals
#pragma section-numbers off
- Release goals for 3.2.
+ == Release Goals ==
- == High Level-Goals ==
+ There are no currently defined release goals for new versions beyond continued bug fixes and enhancements as discussed on the development list and through bugzilla.
+ == Release Schedule ==
- * lower resource usage: higher throughput and lower memory usage
- * higher accuracy: lower FPs and lower FNs (rules, rules, rules... this also includes some notion of speeding up the mass-check process)
- == High Level Anti-Goals ==
+ The Apache !SpamAssassin project goal is to produce three major or minor release per year with release candidates proposed on or closely to January 30th, April 30th & September 30th of each year.
+ == Release Support ==
- * features: extra options, non-critical changes not related to the above goals, etc. (except perhaps in plugins)
- * option bloat (except perhaps in plugins)
- == Basic reorganization of rules ==
+ A major release is supported for no less than 6 months after the release of the next major release.
+ This means that as of July 27, 2010, all versions prior to 3.3.0 are considered unsupported and when 3.4.0 is released, 3.3.X will be supported for at least 6 more months.
- * SVN external for rules (using "if" for version-specific rules)
- * separate 50_scores.cf into input and output files
- * traversing configuration directories
-
- == Memory Usage ==
-
- We should probably evolve some understanding of what we want to convert
- to plugins. Here's the list:
-
- * finish transition away from AWL and finish replacing with "History" plugin including backwards compatibility
- * plugin-ize Bayes
- * move user preference configuration code to plugins
- * plugin-ize whitelisting
-
- == Performance/Speed ==
-
- * Predictive autolearn? do check before bayes_check, if we are likely to autolearn, go r/w instead of r/o. Can implement on first bayes_check call.
- * Don't bother caching full/decoded/etc at start in PMS. how much caching do we do now? multiple times in PMS? may not be an issue due to references.
- * short circuiting ideas:
- * set certain rules as SC if hit
- * USER_IN_WHITELIST, USER_IN_BLACKLIST (not DEF)
- * BSP
- * HABEAS
- * allow SC on ham score (ie: < #)
- * allow SC on spam score (ie: > #)
- * should autolearn skip SC msgs? should we always do autolearn in the appropriate direction?
- * AWL should be skipped during SC
- * SC rules should have a negative priority so they run first
- * do *not* do score check per rule, do it either per priority or rule type (header, body, etc.)
- * SC will require is_spam SC as score + required_hits will be at odds
- * add SC header macro (get_tag)
- * SC for S/O 1.000 rules? how about S/O near 1? BAYES_99, etc.
- * Some form of order/priority rearrangement:
- * Blacklist: short
- * Whitelist: user/admin wants it
- * BSP/Habeas: reputable, non-forgable
- * Other SC Rules: as early as possible
- * Other Local Rules: lightweight
-
- == Accuracy Ideas ==
-
- * network test, do DNS lookups on the HELO (A, NS, and SURBL)
- * network test, do DNS lookups on the EnvelopeFrom (SURBL)
-
- == Uncategorized ==
-
- * use personal branches for major breakage changes (read: crazy stuff)
-
= Old Release Goals =
* [[http://wiki.apache.org/spamassassin/ReleaseGoals?action=raw&rev=4|3.1.x]]
+ * [[http://wiki.apache.org/spamassassin/ReleaseGoals?action=raw&rev=10|3.2.x]]