On Tuesday 14 April 2009 10:50:23 Justin Mason wrote: > > In general we've been a little light on dev effort lately.. perhaps we > > need to start rounding up for a 3.3.0 release. > > yeah, I think we should. > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5752 > 'Let's get rid of the default rules dir and make sa-update mandatory' > > is the only bug that IMO _needs_ to be done. it'd be nice to get the > BerkeleyDB plugin in, too, though, and I'm sure there are a few > others. > > we really need to get some tuits together ;)
I agree it's about time to get 3.3.0 wrapped up. There is some useful new code there along with a couple of bug fixes, just sitting there. People are reluctant to use a non-released version, even though I'd say it is just as stable if not more than 3.2.5. As new problems are being reported faster than the old ones are being closed, it would be an illusion to wait for a majority of open tickets to be closed before a release. I would too like to see the BerkeleyDB bayes backend to be sorted out before the release. I made a couple of minor attempts to deal with the more obvious issues, but it would be nice to get some help from Michael, its author (or some other interested party), and some experience from a production use. Bug 6046. With DKIM ADSP rules I'm a bit stuck because 3.2.5 and 3.3 use the same rules set (I'd like to add few adsp_override rules, drop now defunct DKIM_POLICY_SIGNALL, DKIM_POLICY_SIGNSOME, DKIM_POLICY_TESTING; and DKIM_VERIFIED now replaced by DKIM_VALID and DKIM_VALID_AU). In principle the 'if version' could be used, but it gets unsightly. If I remember right, we already heard suggestion (by JM?) to split again the rules by version. Or maybe there could be a common subset, along with a per-branch set. I would like to get a dkim tests operational again. A few testing public keys need to be published in a spamassassin.org zone (I know, Justin can push them to DNS, I just need to provide them). This is the main item I need to work on for 3.3. Perhaps 3.3 is a good opportunity to make some Perl modules required or phased out. One example that comes to mind is making Time::HiRes a requirement - several SA modules are now jumping hoops and perform suboptimally when they need to deal with integer seconds. Another is perhaps to replace a Digest::SHA1 (which can only do a sha1) with a Digest::SHA (which can do a sha1 as well as sha256). The sha256 is required by a DKIM plugin, and Digest::SHA is upwards compatible with Digest::SHA1. I can do some benchmarking if there is a speed concern (sha1 is also used by Bayes). Perhaps now the DomainKeys plugin could be removed, as its underlying module is no longer supported, and its functionality is covered by a DKIM plugin. Mark
