jm at jmason
Apr 14, 2009, 5:07 AM
Post #18 of 60
(2772 views)
Permalink
|
On Tue, Apr 14, 2009 at 12:21, Mark Martinec <Mark.Martinec+sa [at] ijs> wrote:
> 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.
Yes, agreed. BTW, we generally use the Pri field in bugzilla to
determine importance of tickets to handle this issue. Here's a quick
guide to how to triage the 3.3.0 queue in our BZ:
- if a ticket has no patch, is a feature request or similar "I want a
pony" wishful thinking ;), and you think it's almost certainly not
going to be fixed for the release, move it to the "Future" milestone
- if a ticket *needs* to be fixed before release, set severity to "Blocker"
- if it should be fixed before release if possible, move Pri up to "1"
- if a ticket has a patch, or seems fixable for the release, set Pri
to somewhere between 2 and 4 based on your idea of its relative
importance
- if the ticket is a feature req with no suitable patch, set Pri to
"5", where it's probably not going to be fixed but is still "on the
radar".
You can then see the "queue" by searching against the 3.3.0 target milestone
and sorting by Pri.
I expect we'll release 3.3.0 with a lot of tickets in the Pri "3" to
"5" range. ;)
> 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.
is already in that list with Pri=3, which is about right. I hope we
can get this working...
> 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 think we should split it again. the attempts to use a common subset of rules
has caused a *lot* of integration/dependency problems IMO. Here's what
I posted over a year ago(!):
'I would also like to get rid of the "rulesrc" external, and instead
just put its contents into each branch, separately. I don't think the
idea of sharing rules in this way between branches has worked out; in my
opinion it's caused more trouble than help (unanticipated dependencies,
complexity, SVN external = horrible anyway). Is anyone still attached to
this idea?'
there were no replies, so that sounds good ;)
> 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.
is there a bug for that? there probably should be...
> 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.
+1, that seems ok to me. a lot of distros bundle Time::HiRes now.
> 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).
I'd be more concerned about availability, esp whether or not it's
available in common distro packages (Ubuntu, Debian and Red Hat
particularly).
> 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.
+1
--j.
|
1
