You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2008/08/28 12:47:50 UTC

Re: 3.3.0 plans

Warren Togami writes:
> Justin Mason wrote:
> > ok, what bugs really need to be fixed for 3.3.0?  feel free to set
> > Priority on bugs on the 3.3.0 milestone.  in my opinion this is the
> > only real blocker:
> > 
> > 5752    2008-02-04  nor     P1      Let's get rid of the default rules dir
> > and make sa-update mandatory
> > 
> > All the rest is just icing (and the odd non-blocker bug, but who's
> > counting ;).
> 
> It has been a while since this last update.  What is the status of 3.3.0 
> now?

hi Warren -- 

There's been no real motion -- we've been infrequently bashing the odd bug
in the 3.3.0 list, but we have no concrete release schedule yet.  Sorry
about that...

--j.

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
> > 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.

> > 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 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 ;)

Just needs to be done :)

> > 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...

Bug 6100, now open.
DKIM keys are now ready, test mail samples need to be prepared.

> > 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.

Bug 6095, now resolved.

> > 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

Bug 6098, now resolved.


  Mark

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
On Wednesday 15 April 2009 03:53:17 Michael Alan Dorman wrote:
> I also read a post just this morning from a linux kernel hacker who's
> working with BDB, who fingered RMW as causing problems for him, so I
> may check that as well.

Btw, I'm using bdb with DB_INIT_CDB | DB_INIT_MPOOL
(cursor locking with Concurrent Data Store) in amavisd,
and it is very reliable. I also keep signals disabled around
each short code section operating under a lock.
No secondary keys in use though.

  Mark

Re: 3.3.0 plans

Posted by Michael Alan Dorman <md...@ironicdesign.com>.
> I don't know if it would be helpful or not, but you may wish to look
> at the OpenLDAP back-bdb and back-hdb backends, which use BDB
> extensively, and are highly performant.

It's a good recommendation.

I also read a post just this morning from a linux kernel hacker who's
working with BDB, who fingered RMW as causing problems for him, so I
may check that as well.

Mike.

Re: 3.3.0 plans

Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Tuesday, April 14, 2009 9:29 AM -0400 Michael Alan Dorman 
<md...@ironicdesign.com> wrote:

> Sorry, I've been swamped by work for the last couple of months.
>
> I haven't had time to pull in your changes from a month or two ago,
> which I want to look at, but I have done some work independently.
>
> The solution to the consistency problems you were running into is, as
> far as I can discern, to use transactions---which, to my eye, would
> be perfectly fine: it slows things down a little bit, but it's still
> faster than the full-on SQL back-ends.
>
> Unfortunately, when I do that, I then have problems with BDB
> complaining about lack of available transaction slots...even when
> there's only ever been one or two transactions in play at one time.
>
> (Oh, and you can only adjust the number of transaction slots using a
> DB_CONFIG file, which is a whole other annoyance---that's just part of
> the BDB API that isn't exposed in the perl module.)
>
> Perhaps the combination of your changes and mine will make some forward
> progress.  I'm going to be very busy for the next couple of weeks, but
> maybe I can carve out some time to reconcile our changes and start up
> some tests.

I don't know if it would be helpful or not, but you may wish to look at the 
OpenLDAP back-bdb and back-hdb backends, which use BDB extensively, and are 
highly performant.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Re: 3.3.0 plans

Posted by Michael Alan Dorman <md...@ironicdesign.com>.
> 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.

Sorry, I've been swamped by work for the last couple of months.

I haven't had time to pull in your changes from a month or two ago,
which I want to look at, but I have done some work independently.

The solution to the consistency problems you were running into is, as
far as I can discern, to use transactions---which, to my eye, would
be perfectly fine: it slows things down a little bit, but it's still
faster than the full-on SQL back-ends.

Unfortunately, when I do that, I then have problems with BDB
complaining about lack of available transaction slots...even when
there's only ever been one or two transactions in play at one time.

(Oh, and you can only adjust the number of transaction slots using a
DB_CONFIG file, which is a whole other annoyance---that's just part of
the BDB API that isn't exposed in the perl module.)

Perhaps the combination of your changes and mine will make some forward
progress.  I'm going to be very busy for the next couple of weeks, but
maybe I can carve out some time to reconcile our changes and start up
some tests.

Mike.

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Tue, Apr 14, 2009 at 12:21, Mark Martinec <Ma...@ijs.si> 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.

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Thu, May 28, 2009 at 19:35, Warren Togami <wt...@redhat.com> wrote:
> On 05/28/2009 03:48 AM, Justin Mason wrote:
>>
>> It would be quite possible to do this, given a sufficiently-dedicated
>> release guy pushing
>> it.  It takes about 2 months to get through mass-checks, generate good
>> scores,
>> etc.  Unfortunately, I'm out for this job, as child #2 is about to be born
>> any
>> day now ;)
>>
>> BTW in the short term, if ppl want to help 3.3.0 release plans, I suggest
>> trying
>> out the SVN trunk code as "dogfood".  I've been doing this for the last
>> couple
>> of years with very good results; I can't recall the last time I had to
>> restart my
>> spamd, for example, or spotted an FP...
>>
>> --j.
>
> Is the release process and tools used documented?  Anyone else from the core
> team might be able to do it?

AFAIK, yep...

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 05/28/2009 03:48 AM, Justin Mason wrote:
> It would be quite possible to do this, given a sufficiently-dedicated
> release guy pushing
> it.  It takes about 2 months to get through mass-checks, generate good scores,
> etc.  Unfortunately, I'm out for this job, as child #2 is about to be born any
> day now ;)
>
> BTW in the short term, if ppl want to help 3.3.0 release plans, I suggest trying
> out the SVN trunk code as "dogfood".  I've been doing this for the last couple
> of years with very good results; I can't recall the last time I had to
> restart my
> spamd, for example, or spotted an FP...
>
> --j.

Is the release process and tools used documented?  Anyone else from the 
core team might be able to do it?

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Thu, May 28, 2009 at 05:10, Warren Togami <wt...@redhat.com> wrote:
> On 04/14/2009 07:21 AM, Mark Martinec wrote:
>>
>> 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.
>>
>
> Might it be feasible to get 3.3.0 out sometime during the Fedora 12 dev
> cycle?  It seems there is maybe 2-3 months.  A fresh spamassassin making
> this release might possibly be particularly more important than other
> releases for unnamed reasons...
>
> March 2008 Justin Mason mentions only two major bugs necessary to be fixed
> before 3.3.0.  Around that time 3.3.0 was considered to be superior to
> 3.2.x.  Is it still considered better than 3.2.x?
>
> Might it be a good idea to set a target date?  Time-based releases tend to
> work well for projects.  Those stated deadlines tend to be stretched a bit
> in reality, but at least goals were set and people work toward those goals.

It would be quite possible to do this, given a sufficiently-dedicated
release guy pushing
it.  It takes about 2 months to get through mass-checks, generate good scores,
etc.  Unfortunately, I'm out for this job, as child #2 is about to be born any
day now ;)

BTW in the short term, if ppl want to help 3.3.0 release plans, I suggest trying
out the SVN trunk code as "dogfood".  I've been doing this for the last couple
of years with very good results; I can't recall the last time I had to
restart my
spamd, for example, or spotted an FP...

--j.

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Thu, May 28, 2009 at 05:10, Warren Togami <wt...@redhat.com> wrote:
> On 04/14/2009 07:21 AM, Mark Martinec wrote:
>>
>> 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.
>>
>
> Might it be feasible to get 3.3.0 out sometime during the Fedora 12 dev
> cycle?  It seems there is maybe 2-3 months.  A fresh spamassassin making
> this release might possibly be particularly more important than other
> releases for unnamed reasons...
>
> March 2008 Justin Mason mentions only two major bugs necessary to be fixed
> before 3.3.0.  Around that time 3.3.0 was considered to be superior to
> 3.2.x.  Is it still considered better than 3.2.x?
>
> Might it be a good idea to set a target date?  Time-based releases tend to
> work well for projects.  Those stated deadlines tend to be stretched a bit
> in reality, but at least goals were set and people work toward those goals.

It would be quite possible to do this, given a sufficiently-dedicated
release guy pushing
it.  It takes about 2 months to get through mass-checks, generate good scores,
etc.  Unfortunately, I'm out for this job, as child #2 is about to be born any
day now ;)

BTW in the short term, if ppl want to help 3.3.0 release plans, I suggest trying
out the SVN trunk code as "dogfood".  I've been doing this for the last couple
of years with very good results; I can't recall the last time I had to
restart my
spamd, for example, or spotted an FP...

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 04/14/2009 07:21 AM, Mark Martinec wrote:
>
> 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.
>

Might it be feasible to get 3.3.0 out sometime during the Fedora 12 dev 
cycle?  It seems there is maybe 2-3 months.  A fresh spamassassin making 
this release might possibly be particularly more important than other 
releases for unnamed reasons...

March 2008 Justin Mason mentions only two major bugs necessary to be 
fixed before 3.3.0.  Around that time 3.3.0 was considered to be 
superior to 3.2.x.  Is it still considered better than 3.2.x?

Might it be a good idea to set a target date?  Time-based releases tend 
to work well for projects.  Those stated deadlines tend to be stretched 
a bit in reality, but at least goals were set and people work toward 
those goals.

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
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

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Tue, Apr 14, 2009 at 01:48, Matt Kettler <mk...@verizon.net> wrote:
> Warren Togami wrote:
>> On 08/28/2008 06:47 AM, Justin Mason wrote:
>>>
>>> hi Warren --
>>>
>>> There's been no real motion -- we've been infrequently bashing the
>>> odd bug
>>> in the 3.3.0 list, but we have no concrete release schedule yet.  Sorry
>>> about that...
>>>
>>> --j.
>>
>> How are things going now?
>>
>> Warren Togami
>> wtogami@redhat.com
>>
> Well, a first hit would be looking at bugzilla
>
>
> https://issues.apache.org/SpamAssassin/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailtype1=substring&emailtype2=substring&field-1-0-0=target_milestone&field-1-1-0=bug_status&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&target_milestone=3.3.0&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=3.3.0&value-1-1-0=NEW%2CASSIGNED%2CREOPENED&value0-0-0=&order=bugs.priority&query_based_on=
>
> 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 ;)

--j.

Re: 3.3.0 plans

Posted by Matt Kettler <mk...@verizon.net>.
Warren Togami wrote:
> On 08/28/2008 06:47 AM, Justin Mason wrote:
>>
>> hi Warren --
>>
>> There's been no real motion -- we've been infrequently bashing the
>> odd bug
>> in the 3.3.0 list, but we have no concrete release schedule yet.  Sorry
>> about that...
>>
>> --j.
>
> How are things going now?
>
> Warren Togami
> wtogami@redhat.com
>
Well, a first hit would be looking at bugzilla


https://issues.apache.org/SpamAssassin/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailtype1=substring&emailtype2=substring&field-1-0-0=target_milestone&field-1-1-0=bug_status&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&target_milestone=3.3.0&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=3.3.0&value-1-1-0=NEW%2CASSIGNED%2CREOPENED&value0-0-0=&order=bugs.priority&query_based_on=

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.



Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 08/28/2008 06:47 AM, Justin Mason wrote:
> Warren Togami writes:
>> Justin Mason wrote:
>>> ok, what bugs really need to be fixed for 3.3.0?  feel free to set
>>> Priority on bugs on the 3.3.0 milestone.  in my opinion this is the
>>> only real blocker:
>>>
>>> 5752    2008-02-04  nor     P1      Let's get rid of the default rules dir
>>> and make sa-update mandatory
>>>
>>> All the rest is just icing (and the odd non-blocker bug, but who's
>>> counting ;).
>> It has been a while since this last update.  What is the status of 3.3.0
>> now?
>
> hi Warren --
>
> There's been no real motion -- we've been infrequently bashing the odd bug
> in the 3.3.0 list, but we have no concrete release schedule yet.  Sorry
> about that...
>
> --j.

How are things going now?

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans, what next?

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jul 15, 2009 at 12:17, Justin Mason<jm...@jmason.org> wrote:
> On Wed, Jul 15, 2009 at 11:51, Warren Togami<wt...@redhat.com> wrote:
>> On 07/15/2009 06:41 AM, Justin Mason wrote:
>>>>
>>>> Do we have enough variety of users submitting nightly mass check data?
>>>
>>> we still need some more, I think.
>>>
>>> MSECS      SPAM%     HAM%     S/O    RANK   SCORE  NAME WHO/AGE
>>> 0.00000  46.7930   0.0431   0.999    0.96    0.01  T_CN_URL
>>> 0.00000   1.3699   0.0000   1.000    0.46    0.01  T_CN_URL bb-jhardin
>>> 0.00000  68.2628   0.0000   1.000    0.99    0.01  T_CN_URL bb-jm
>>> 0.00000  44.9004   0.0132   1.000    0.99    0.01  T_CN_URL dos
>>> 0.00000  19.0590   0.0160   0.999    0.94    0.01  T_CN_URL jm
>>> 0.00000   2.7273   0.0000   1.000    0.75    0.01  T_CN_URL wtogami
>>> 0.00000   5.6111   0.2874   0.951    0.66    0.01  T_CN_URL zmi
>>>
>>
>> What do each of these columns mean?
>
> see http://wiki.apache.org/spamassassin/MassCheck

uh, actually, http://wiki.apache.org/spamassassin/HitFrequencies


-- 
--j.

Re: 3.3.0 plans, what next?

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jul 15, 2009 at 11:51, Warren Togami<wt...@redhat.com> wrote:
> On 07/15/2009 06:41 AM, Justin Mason wrote:
>>>
>>> Do we have enough variety of users submitting nightly mass check data?
>>
>> we still need some more, I think.
>>
>> MSECS      SPAM%     HAM%     S/O    RANK   SCORE  NAME WHO/AGE
>> 0.00000  46.7930   0.0431   0.999    0.96    0.01  T_CN_URL
>> 0.00000   1.3699   0.0000   1.000    0.46    0.01  T_CN_URL bb-jhardin
>> 0.00000  68.2628   0.0000   1.000    0.99    0.01  T_CN_URL bb-jm
>> 0.00000  44.9004   0.0132   1.000    0.99    0.01  T_CN_URL dos
>> 0.00000  19.0590   0.0160   0.999    0.94    0.01  T_CN_URL jm
>> 0.00000   2.7273   0.0000   1.000    0.75    0.01  T_CN_URL wtogami
>> 0.00000   5.6111   0.2874   0.951    0.66    0.01  T_CN_URL zmi
>>
>
> What do each of these columns mean?

see http://wiki.apache.org/spamassassin/MassCheck .  But the only bit
that's relevant to this discussion is the "WHO" part -- ie those
contributor accounts at the end of each line.

--j.

Re: 3.3.0 plans, what next?

Posted by Warren Togami <wt...@redhat.com>.
On 07/15/2009 06:41 AM, Justin Mason wrote:
>> Do we have enough variety of users submitting nightly mass check data?
>
> we still need some more, I think.
>
> MSECS      SPAM%     HAM%     S/O    RANK   SCORE  NAME WHO/AGE
> 0.00000  46.7930   0.0431   0.999    0.96    0.01  T_CN_URL
> 0.00000   1.3699   0.0000   1.000    0.46    0.01  T_CN_URL bb-jhardin
> 0.00000  68.2628   0.0000   1.000    0.99    0.01  T_CN_URL bb-jm
> 0.00000  44.9004   0.0132   1.000    0.99    0.01  T_CN_URL dos
> 0.00000  19.0590   0.0160   0.999    0.94    0.01  T_CN_URL jm
> 0.00000   2.7273   0.0000   1.000    0.75    0.01  T_CN_URL wtogami
> 0.00000   5.6111   0.2874   0.951    0.66    0.01  T_CN_URL zmi
>

What do each of these columns mean?

Warren

Re: 3.3.0 plans, what next?

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jul 15, 2009 at 04:14, Warren Togami<wt...@redhat.com> wrote:
> Thanks for kicking this off.  My RPM packages with packaged rules seem to be
> working well on RHEL4, RHEL5 and Fedora 10+.

excellent!

> Do we have enough variety of users submitting nightly mass check data?

we still need some more, I think.

MSECS      SPAM%     HAM%     S/O    RANK   SCORE  NAME WHO/AGE
0.00000  46.7930   0.0431   0.999    0.96    0.01  T_CN_URL
0.00000   1.3699   0.0000   1.000    0.46    0.01  T_CN_URL bb-jhardin
0.00000  68.2628   0.0000   1.000    0.99    0.01  T_CN_URL bb-jm
0.00000  44.9004   0.0132   1.000    0.99    0.01  T_CN_URL dos
0.00000  19.0590   0.0160   0.999    0.94    0.01  T_CN_URL jm
0.00000   2.7273   0.0000   1.000    0.75    0.01  T_CN_URL wtogami
0.00000   5.6111   0.2874   0.951    0.66    0.01  T_CN_URL zmi

That's not bad, but it could be better.  In numbers, the nonspam is
overwhelmingly coming from my corpus and Daryl's (which has some FPs,
I need to mail those on to you D).


> What remains to be fixed before 3.3.0?

can you see this?
https://issues.apache.org/SpamAssassin/buglist.cgi?cmdtype=runnamed&namedcmd=33bugs

if not, try this:

https://issues.apache.org/SpamAssassin/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&target_milestone=3.3.0&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&known_name=33bugs&query_based_on=33bugs&field0-0-0=noop&type0-0-0=noop&value0-0-0=

very little needs to be done.  Right now I'm thinking just the P1s and P2s:

6143    	nor  	P1  	NEW  	  	Rule2XSBody segfaults due to rule
containing NUL chars
6144 	blo 	P1 	NEW 		write changes list for 3.3.0 release
6155 	blo 	P1 	NEW 		generate new scores for 3.3.0 release
4949 	nor 	P2 	NEW 		spamd shutting down when unable to fork new processes
6003 	nor 	P2 	NEW 		whitelist_from_rcvd propagates to other users
6132 	enh 	P2 	REOP 		FreeMail plugin
6150 	maj 	P2 	REOP 		spamd fails: /usr/bin/spamd line 2504

> What is a theoretical schedule for 3.3.0?

I haven't come up with real dates, but I think we could have this
released (ie out of beta) in 2 months.

--j.

Re: 3.3.0 plans, what next?

Posted by Warren Togami <wt...@redhat.com>.
Thanks for kicking this off.  My RPM packages with packaged rules seem 
to be working well on RHEL4, RHEL5 and Fedora 10+.

Do we have enough variety of users submitting nightly mass check data?

What remains to be fixed before 3.3.0?

What is a theoretical schedule for 3.3.0?

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Tue, Jul 7, 2009 at 10:07, Warren Togami<wt...@redhat.com> wrote:
> On 07/07/2009 04:57 AM, Justin Mason wrote:
>>
>> On Mon, Jul 6, 2009 at 23:36, Warren Togami<wt...@redhat.com>  wrote:
>>>
>>> On 07/06/2009 06:12 PM, Justin Mason wrote:
>>>>
>>>> crap, you're right. :(
>>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6147
>>>>
>>>> there's a patch there that appears to fix it.  does it work for you?
>>>>
>>>> --j.
>>>
>>> A patch only for MANIFEST* going to copy *.pre files from the tarball,
>>> when
>>> the tarball lacks those files?
>>>
>>> It seems MANIFEST* only effects what goes from the SCM into tarball.
>>
>> yep, you'd have to rebuild the tarball.
>>
>>> Anyhow, I'm adding the *.pre files manually for the initial package.
>>
>> ok
>
> But now I'm unable to push this packaged due to the tainting issue.  Is this
> is in fact a perl bug, not spamassassin's fault?  This is the latest version
> of upstream perl.

I haven't looked into it, but iirc, it's a perl bug. (at least a bug
in a module bundled with perl.)  We trigger it due to our extensive
use of -T (taint mode).  As Mark notes, we may be able to work around
it in our code though.

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 07/07/2009 04:57 AM, Justin Mason wrote:
> On Mon, Jul 6, 2009 at 23:36, Warren Togami<wt...@redhat.com>  wrote:
>> On 07/06/2009 06:12 PM, Justin Mason wrote:
>>> crap, you're right. :(
>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6147
>>>
>>> there's a patch there that appears to fix it.  does it work for you?
>>>
>>> --j.
>> A patch only for MANIFEST* going to copy *.pre files from the tarball, when
>> the tarball lacks those files?
>>
>> It seems MANIFEST* only effects what goes from the SCM into tarball.
>
> yep, you'd have to rebuild the tarball.
>
>> Anyhow, I'm adding the *.pre files manually for the initial package.
>
> ok

But now I'm unable to push this packaged due to the tainting issue.  Is 
this is in fact a perl bug, not spamassassin's fault?  This is the 
latest version of upstream perl.

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Mon, Jul 6, 2009 at 23:36, Warren Togami<wt...@redhat.com> wrote:
> On 07/06/2009 06:12 PM, Justin Mason wrote:
>>
>> crap, you're right. :(
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6147
>>
>> there's a patch there that appears to fix it.  does it work for you?
>>
>> --j.
>
> A patch only for MANIFEST* going to copy *.pre files from the tarball, when
> the tarball lacks those files?
>
> It seems MANIFEST* only effects what goes from the SCM into tarball.

yep, you'd have to rebuild the tarball.

> Anyhow, I'm adding the *.pre files manually for the initial package.

ok

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 06:12 PM, Justin Mason wrote:
>
> crap, you're right. :(
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6147
>
> there's a patch there that appears to fix it.  does it work for you?
>
> --j.

A patch only for MANIFEST* going to copy *.pre files from the tarball, 
when the tarball lacks those files?

It seems MANIFEST* only effects what goes from the SCM into tarball.

Anyhow, I'm adding the *.pre files manually for the initial package.

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Mon, Jul 6, 2009 at 22:40, Warren Togami<wt...@redhat.com> wrote:
> On 07/06/2009 05:32 PM, Justin Mason wrote:
>>
>> On Mon, Jul 6, 2009 at 21:05, Warren Togami<wt...@redhat.com>  wrote:
>>>
>>> On 07/06/2009 04:00 PM, Mark Martinec wrote:
>>>>
>>>> Warren,
>>>>
>>>>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>>>>>
>>>>>> The public alpha release was announced yesterday on the users mailing
>>>>>> list:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>>>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>>>>>
>>>>> I'm having trouble getting it to run on Fedora 11.
>>>>>
>>>>> [root@newcaprica spamassassin]#
>>>>>   sa-update config: no configuration text or files found!
>>>>>   do you need to run 'sa-update'?
>>>>> check: no loaded plugin implements 'check_main': cannot scan!
>>>>> Check the necessary '.pre' files are in the config directory.
>>>>
>>>> Yes, and?  Did you run sa-update???
>>>>
>>>> The 3.3 no longer comes with rules in the same package.
>>>> These must be installed separately with 'sa-update',
>>>> which either fetches them from the net, or can install
>>>> them from a tar - which is in the same directory
>>>> as 3.3.0-alpha1 is.
>>>>
>>>>   Mark
>>>
>>> sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
>>> files.
>>>
>>
>> this sounds like our RPM spec file is buggy -- does it work if
>> installed from the tgz?
>>
>> --j.
>
> This isn't the upstream RPM spec file.  This is Fedora's spec file.
>
> How can it copy the *.pre files into the RPM if the *.pre files do not exist
> in the tarball's rules/ directory?

crap, you're right. :(
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6147

there's a patch there that appears to fix it.  does it work for you?

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 05:32 PM, Justin Mason wrote:
> On Mon, Jul 6, 2009 at 21:05, Warren Togami<wt...@redhat.com>  wrote:
>> On 07/06/2009 04:00 PM, Mark Martinec wrote:
>>> Warren,
>>>
>>>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>>>> The public alpha release was announced yesterday on the users mailing
>>>>> list:
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>>>> I'm having trouble getting it to run on Fedora 11.
>>>>
>>>> [root@newcaprica spamassassin]#
>>>>    sa-update config: no configuration text or files found!
>>>>    do you need to run 'sa-update'?
>>>> check: no loaded plugin implements 'check_main': cannot scan!
>>>> Check the necessary '.pre' files are in the config directory.
>>> Yes, and?  Did you run sa-update???
>>>
>>> The 3.3 no longer comes with rules in the same package.
>>> These must be installed separately with 'sa-update',
>>> which either fetches them from the net, or can install
>>> them from a tar - which is in the same directory
>>> as 3.3.0-alpha1 is.
>>>
>>>    Mark
>> sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
>> files.
>>
>
> this sounds like our RPM spec file is buggy -- does it work if
> installed from the tgz?
>
> --j.

This isn't the upstream RPM spec file.  This is Fedora's spec file.

How can it copy the *.pre files into the RPM if the *.pre files do not 
exist in the tarball's rules/ directory?

Warren


Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Mon, Jul 6, 2009 at 21:05, Warren Togami<wt...@redhat.com> wrote:
> On 07/06/2009 04:00 PM, Mark Martinec wrote:
>>
>> Warren,
>>
>>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>>>
>>>> The public alpha release was announced yesterday on the users mailing
>>>> list:
>>>>
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>>>
>>> I'm having trouble getting it to run on Fedora 11.
>>>
>>> [root@newcaprica spamassassin]#
>>>   sa-update config: no configuration text or files found!
>>>   do you need to run 'sa-update'?
>>> check: no loaded plugin implements 'check_main': cannot scan!
>>> Check the necessary '.pre' files are in the config directory.
>>
>> Yes, and?  Did you run sa-update???
>>
>> The 3.3 no longer comes with rules in the same package.
>> These must be installed separately with 'sa-update',
>> which either fetches them from the net, or can install
>> them from a tar - which is in the same directory
>> as 3.3.0-alpha1 is.
>>
>>   Mark
>
> sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre
> files.
>

this sounds like our RPM spec file is buggy -- does it work if
installed from the tgz?

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 04:00 PM, Mark Martinec wrote:
> Warren,
>
>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>> The public alpha release was announced yesterday on the users mailing
>>> list:
>>>
>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
>>> 3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>> I'm having trouble getting it to run on Fedora 11.
>>
>> [root@newcaprica spamassassin]#
>>    sa-update config: no configuration text or files found!
>>    do you need to run 'sa-update'?
>> check: no loaded plugin implements 'check_main': cannot scan!
>> Check the necessary '.pre' files are in the config directory.
>
> Yes, and?  Did you run sa-update???
>
> The 3.3 no longer comes with rules in the same package.
> These must be installed separately with 'sa-update',
> which either fetches them from the net, or can install
> them from a tar - which is in the same directory
> as 3.3.0-alpha1 is.
>
>    Mark

sa-update is failing due to the lack of the /etc/mail/spamassassin/*.pre 
files.

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
Warren,

> On 07/03/2009 10:37 PM, Matt Kettler wrote:
> > The public alpha release was announced yesterday on the users mailing
> > list:
> >
> > http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%
> >3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>
> I'm having trouble getting it to run on Fedora 11.
>
> [root@newcaprica spamassassin]#
>   sa-update config: no configuration text or files found!
>   do you need to run 'sa-update'?
> check: no loaded plugin implements 'check_main': cannot scan!
> Check the necessary '.pre' files are in the config directory.

Yes, and?  Did you run sa-update???

The 3.3 no longer comes with rules in the same package.
These must be installed separately with 'sa-update',
which either fetches them from the net, or can install
them from a tar - which is in the same directory
as 3.3.0-alpha1 is.

  Mark

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Mon, Jun 29, 2009 at 22:24, Mark Martinec<Ma...@ijs.si> wrote:
> Justin wrote:
>
>> > Why end of the week if nothing on the list is blockers?
>>
>> ok ok.  good point ;)
>>
>> Let's give it 3 days to garner some comments and possibly close out a
>> few of those P1s and P2s.  Wednesday evening...
>
> Wednesday evening is good (or even Thursday),
> I could announce its availability on Friday at a German mail server conference
> http://www.heinlein-support.de/web/akademie/mailserver-konferenz-2009/

great! we'll need to get 3 +1's from committers to release it though ;)  given
that you and I will be 2 of those, hopefully,  I don't think this will
be a problem.

--j.

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
Justin wrote:

> > Why end of the week if nothing on the list is blockers?
>
> ok ok.  good point ;)
>
> Let's give it 3 days to garner some comments and possibly close out a
> few of those P1s and P2s.  Wednesday evening...

Wednesday evening is good (or even Thursday),
I could announce its availability on Friday at a German mail server conference
http://www.heinlein-support.de/web/akademie/mailserver-konferenz-2009/

  Mark

Re: 3.3.0 plans

Posted by "Kevin A. McGrail" <km...@pccc.com>.
> I'm all for abandoning perl 5.6 with 3.3, although I can accept it one way
> or another. For those in need of perl 5.6 there will still be a 3.2.*.

Please don't say that.  I think we'd like to envision the death of old 
versions and the support of the new tree only as soon as feasible!  I'd 
prefer to write documentation on workarounds such as installing an alternate 
and newer perl alongside the distributions release, using cpan to install 
any necessary modules, and making sure that their install of SA runs with 
/usr/local/perl5.8/bin/perl.  I've never tried this but the theory seems 
more than sound to me.

Regards,
KAM 


Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
On Tuesday 30 June 2009 01:32:16 Karsten Bräckelmann wrote:
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)

Not really, but it seems to be a moment of a sparkling desire
among devels, perhaps too good to be missed, before everybody
leaves for vacation (or babysitting)  ;)

> Is the priority bumping of the 
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?
>
> See my concerns about carrying around old baggage and a need to support
> Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> we miss this opportunity.

I'm all for abandoning perl 5.6 with 3.3, although I can accept it one way
or another. For those in need of perl 5.6 there will still be a 3.2.*.

  Mark

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
2009/6/30 Karsten Bräckelmann <gu...@rudersport.de>:
> On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
>> 2009/6/25 Karsten Bräckelmann <gu...@rudersport.de>:
>
>> > I believe re-thinking the minimum supported Perl version and related
>> > stuff like screwing MakeMaker would be a *really* good target for a new
>> > $minor release.
>> >
>> > How much longer do we want to support Perl 5.6.x? [...]
>
>> my guess is it'll be doable.
>
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)  Is the priority bumping of the
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?

We should have a separate bug for that.

note that again, this issue isn't a blocker for the alpha release. we
can do an alpha before deciding that.
(we may have to add a min-version requirement to Makefile.PL for
ExtUtils::MakeMaker though.)

--j.

Re: 3.3.0 plans

Posted by Sidney Markowitz <si...@sidney.com>.
Karsten Bräckelmann wrote, On 30/6/09 12:27 PM:
> Essentially we would promise actively supporting any issues with Perl
> 5.8, but not necessarily fix it for 5.6, too.

That sounds to me very much like declaring 5.6 as deprecated.

Would that have the right connotations for what both of you have been 
talking about?

  -- sidney


Re: 3.3.0 plans

Posted by "Kevin A. McGrail" <km...@pccc.com>.
> Essentially we would promise actively supporting any issues with Perl
> 5.8, but not necessarily fix it for 5.6, too.

I agree fully with your statements on this!

> It's not about an age-range of obsolete versions being introduced, but
> superseded. Don't think "Perl 5.8 is 7 years old", but "5.6 went old 7
> years ago". How long is that for 5.8?

You make a good point but arbitrary rules are hard with Perl.  Perl in 
practice is just too good in that modules have made it easier to keep 
running for existing installations and security issues that necessitate an 
outright upgrade have been minimal.  Code-forks are a reason to consider 
supporting the next version, though.  Code-forks are evil personified.

Regards,
KAM 


Re: 3.3.0 plans

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Mon, 2009-06-29 at 20:01 -0400, Kevin A. McGrail wrote:
> I would easily vote to require a MakeMaker version if that is the only 
> requirement to keep 5.6.X support to move this release forward.  Anyone 
> supporting a 5.6.x install should be capable of installing requirements that 
> don't necessarily require an entirely new version.

As I've said before (and IIRC Mark implied with his comment 2 years ago
in bugzilla), I'm not about dropping the torch for 5.6. But instead, do
not *claim* we'll always support 5.6.

If it works with 5.6 and some updated Perl modules like MakeMaker, good.
If we can fix an issue for 5.6, good. But do not promise we'll fix and
workaround Perl 5.6 issues, maintaining SA 3.3 until the end of 3.4 --
whenever that'll be. Keep the door open to not back-port critical issues
with Perl 5.6 in 2012, when there's no chance to test it with 5.6 on all
platforms without major headaches.

Essentially we would promise actively supporting any issues with Perl
5.8, but not necessarily fix it for 5.6, too.


> However, I don't support an age-range for supporting perl because even 5.8 
> is already nearly 7 years old having been release in July 2002.

It's not about an age-range of obsolete versions being introduced, but
superseded. Don't think "Perl 5.8 is 7 years old", but "5.6 went old 7
years ago". How long is that for 5.8?


> > Did we decide about that yet? :)  Is the priority bumping of the
> > MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> > want a separate bug to track bumping requirements in two places?
> >
> > See my concerns about carrying around old baggage and a need to support
> > Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> > we miss this opportunity.

-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: 3.3.0 plans

Posted by "Kevin A. McGrail" <km...@pccc.com>.
I would easily vote to require a MakeMaker version if that is the only 
requirement to keep 5.6.X support to move this release forward.  Anyone 
supporting a 5.6.x install should be capable of installing requirements that 
don't necessarily require an entirely new version.

However, I don't support an age-range for supporting perl because even 5.8 
is already nearly 7 years old having been release in July 2002.

Regards,
KAM


----- Original Message ----- 
From: "Karsten Bräckelmann" <gu...@rudersport.de>
To: <de...@spamassassin.apache.org>
Sent: Monday, June 29, 2009 7:32 PM
Subject: Re: 3.3.0 plans


> On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
>> 2009/6/25 Karsten Bräckelmann <gu...@rudersport.de>:
>
>> > I believe re-thinking the minimum supported Perl version and related
>> > stuff like screwing MakeMaker would be a *really* good target for a new
>> > $minor release.
>> >
>> > How much longer do we want to support Perl 5.6.x? [...]
>
>> my guess is it'll be doable.
>
> BTW, since you're about to push an alpha release...
>
> Did we decide about that yet? :)  Is the priority bumping of the
> MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
> want a separate bug to track bumping requirements in two places?
>
> See my concerns about carrying around old baggage and a need to support
> Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
> we miss this opportunity.
>
>
> -- 
> char 
> *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
> main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? 
> c<<=1:
> (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ 
> putchar(t[s]);h=m;s=0; }}}
> 


Re: 3.3.0 plans

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2009-06-25 at 09:51 +0100, Justin Mason wrote:
> 2009/6/25 Karsten Bräckelmann <gu...@rudersport.de>:

> > I believe re-thinking the minimum supported Perl version and related
> > stuff like screwing MakeMaker would be a *really* good target for a new
> > $minor release.
> >
> > How much longer do we want to support Perl 5.6.x? [...]

> my guess is it'll be doable.

BTW, since you're about to push an alpha release...

Did we decide about that yet? :)  Is the priority bumping of the
MakeMaker bug an implicit death sentence for Perl 5.6 support, or do we
want a separate bug to track bumping requirements in two places?

See my concerns about carrying around old baggage and a need to support
Perl 5.6 for important back-ports until the end of the 3.4 live-time, if
we miss this opportunity.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
2009/6/25 Karsten Bräckelmann <gu...@rudersport.de>:
> On Wed, 2009-06-24 at 23:00 +0100, Justin Mason wrote:
>> is there anything else that we should sort out before an alpha is viable?
>
> I believe re-thinking the minimum supported Perl version and related
> stuff like screwing MakeMaker would be a *really* good target for a new
> $minor release.
>
> How much longer do we want to support Perl 5.6.x? There are comments in
> bugzilla from years ago, that there's virtually no system without Perl
> 5.8.x for years (counting from the comment, not today).
>
> I'd seriously prefer a "drop support for < Perl 5.8.1" in a separate
> thread, though.

I've done that -- and on the users@ list, since a lot of potential
commenters don't read dev@.  (I've also cc'd my blog to catch the
Planet Perl readers.)

my guess is it'll be doable.

--j.

Re: 3.3.0 plans

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2009-06-24 at 23:00 +0100, Justin Mason wrote:
> is there anything else that we should sort out before an alpha is viable?

I believe re-thinking the minimum supported Perl version and related
stuff like screwing MakeMaker would be a *really* good target for a new
$minor release.

How much longer do we want to support Perl 5.6.x? There are comments in
bugzilla from years ago, that there's virtually no system without Perl
5.8.x for years (counting from the comment, not today).

I'd seriously prefer a "drop support for < Perl 5.8.1" in a separate
thread, though.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


Re: 3.3.0-alpha1 working for anyone?

Posted by Justin Mason <jm...@jmason.org>.
> Checking if your kit is complete...
> Looks good
> 'ENABLE_SSL' is not a known MakeMaker parameter name.
> 'SYSCONFDIR' is not a known MakeMaker parameter name.
> Writing Makefile for Mail::SpamAssassin
> Makefile written by ExtUtils::MakeMaker 6.42
> + /usr/bin/make 'OPTIMIZE=-O2 -g' -j3
>
> spamassassin-3.2.5 does not complain about ENABLE_SSL or SYSCONFDIR in
> MakeMaker.  What changed?  Do we need to adapt?

no, that should be fine.  (we should probably fix it ;)

btw, this should work --

perl Makefile.PL PREFIX=/tmp/sa
make
make install
/tmp/sa/bin/sa-update

does that work for you?  even without an /etc/mail/spamassassin or
/usr/share/spamassassin?  if so it's definitely the .spec file IMO.

--j.

Re: 3.3.0-alpha1 working for anyone?

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 03:59 PM, Michael Parker wrote:
>>
>> spamassassin-3.2.5 rules/ contains the *.pre files.
>> spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.
>>
>> Was this intentional?
>
> Yes. 3.3 requires that you run sa-update after installation to pick up
> the latest rules release. I believe this is documented.
>
> For packagers such as yourself, you'll probably want to have a separate
> rules package for that initial install.
>

[root@newcaprica spamassassin]# sa-update
config: no configuration text or files found! do you need to run 
'sa-update'?
check: no loaded plugin implements 'check_main': cannot scan!
Check the necessary '.pre' files are in the config directory.

Isn't this a chicken and egg problem then?

Warren

Re: 3.3.0-alpha1 working for anyone?

Posted by Michael Parker <pa...@pobox.com>.
On Jul 6, 2009, at 3:46 PM, Warren Togami wrote:

> On 07/06/2009 03:59 PM, Michael Parker wrote:
>> Yes. 3.3 requires that you run sa-update after installation to pick  
>> up
>> the latest rules release. I believe this is documented.
>>
>> For packagers such as yourself, you'll probably want to have a  
>> separate
>> rules package for that initial install.
>>
>> Michael
>
> It appears that we were overzealous in removing the the rules from  
> the tarball?  sa-update does not work all without the *.pre files.  
> Furthermore package upgrades expect the *.pre files to be installed  
> in the newer version of the package as they need to exist as config  
> files.  They are gone from the alpha1 tarball.
>
> Shouldn't the *.pre files be re-added to the tarball rules/  
> directory, without the accompanying rules?  I added them to my  
> tarball and after you install the resulting RPM binary package, sa- 
> update works.
>
>

Perhaps.  Sounds like a bug, can you please file one.

Thanks
Michael



Re: 3.3.0-alpha1 working for anyone?

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 03:59 PM, Michael Parker wrote:
> Yes. 3.3 requires that you run sa-update after installation to pick up
> the latest rules release. I believe this is documented.
>
> For packagers such as yourself, you'll probably want to have a separate
> rules package for that initial install.
>
> Michael

It appears that we were overzealous in removing the the rules from the 
tarball?  sa-update does not work all without the *.pre files. 
Furthermore package upgrades expect the *.pre files to be installed in 
the newer version of the package as they need to exist as config files. 
  They are gone from the alpha1 tarball.

Shouldn't the *.pre files be re-added to the tarball rules/ directory, 
without the accompanying rules?  I added them to my tarball and after 
you install the resulting RPM binary package, sa-update works.

Warren Togami
wtogami@redhat.com

Re: 3.3.0-alpha1 working for anyone?

Posted by Michael Parker <pa...@pobox.com>.
On Jul 6, 2009, at 2:52 PM, Warren Togami wrote:

> On 07/06/2009 03:13 PM, Warren Togami wrote:
>> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>>> The public alpha release was announced yesterday on the users  
>>> mailing
>>> list:
>>>
>>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>>>
>>
>> I'm having trouble getting it to run on Fedora 11.
>>
>> [root@newcaprica spamassassin]# sa-update
>> config: no configuration text or files found! do you need to run
>> 'sa-update'?
>> check: no loaded plugin implements 'check_main': cannot scan!
>> Check the necessary '.pre' files are in the config directory.
>>
>> *** spamassassin-3.2.5 ***
>>
>> [root@newcaprica ~]# cd /etc/mail/spamassassin/
>> [root@newcaprica spamassassin]# ls
>> init.pre local.cf sa-update-keys spamassassin-default.rc
>> spamassassin-helper.sh spamassassin-spamc.rc v310.pre v312.pre  
>> v320.pre
>>
>> *** spamassassin-3.3.0-alpha1 ***
>>
>> [root@newcaprica ~]# cd /etc/mail/spamassassin/
>> [root@newcaprica spamassassin]# ls
>> local.cf sa-update-keys spamassassin-default.rc spamassassin- 
>> helper.sh
>> spamassassin-spamc.rc
>>
>> All of the *.pre files are no longer being installed into our RPM. It
>> seems to pass the test suite though.
>>
>
> spamassassin-3.2.5 rules/ contains the *.pre files.
> spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.
>
> Was this intentional?

Yes.  3.3 requires that you run sa-update after installation to pick  
up the latest rules release.  I believe this is documented.

For packagers such as yourself, you'll probably want to have a  
separate rules package for that initial install.

Michael


>
>
> Is 3.3.0-alpha1 working for anybody?
>
> Possibly a separate issue this is the %build section from our  
> spamassassin.spec file.
>
> %build
> CFLAGS="$RPM_OPT_FLAGS"; export CFLAGS
> %{__perl} Makefile.PL PREFIX=%{_prefix} SYSCONFDIR=%{_sysconfdir}  
> DESTDIR=$RPM_BUILD_ROOT < /dev/null
> %{__make}
>
> Checking if your kit is complete...
> Looks good
> 'ENABLE_SSL' is not a known MakeMaker parameter name.
> 'SYSCONFDIR' is not a known MakeMaker parameter name.
> Writing Makefile for Mail::SpamAssassin
> Makefile written by ExtUtils::MakeMaker 6.42
> + /usr/bin/make 'OPTIMIZE=-O2 -g' -j3
>
> spamassassin-3.2.5 does not complain about ENABLE_SSL or SYSCONFDIR  
> in MakeMaker.  What changed?  Do we need to adapt?
>
> Warren Togami
> wtogami@redhat.com


3.3.0-alpha1 working for anyone?

Posted by Warren Togami <wt...@redhat.com>.
On 07/06/2009 03:13 PM, Warren Togami wrote:
> On 07/03/2009 10:37 PM, Matt Kettler wrote:
>> The public alpha release was announced yesterday on the users mailing
>> list:
>>
>> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E
>>
>
> I'm having trouble getting it to run on Fedora 11.
>
> [root@newcaprica spamassassin]# sa-update
> config: no configuration text or files found! do you need to run
> 'sa-update'?
> check: no loaded plugin implements 'check_main': cannot scan!
> Check the necessary '.pre' files are in the config directory.
>
> *** spamassassin-3.2.5 ***
>
> [root@newcaprica ~]# cd /etc/mail/spamassassin/
> [root@newcaprica spamassassin]# ls
> init.pre local.cf sa-update-keys spamassassin-default.rc
> spamassassin-helper.sh spamassassin-spamc.rc v310.pre v312.pre v320.pre
>
> *** spamassassin-3.3.0-alpha1 ***
>
> [root@newcaprica ~]# cd /etc/mail/spamassassin/
> [root@newcaprica spamassassin]# ls
> local.cf sa-update-keys spamassassin-default.rc spamassassin-helper.sh
> spamassassin-spamc.rc
>
> All of the *.pre files are no longer being installed into our RPM. It
> seems to pass the test suite though.
>

spamassassin-3.2.5 rules/ contains the *.pre files.
spamassassin-3.3.0-alpha1 rules/ is missing *.pre files.

Was this intentional?

Is 3.3.0-alpha1 working for anybody?

Possibly a separate issue this is the %build section from our 
spamassassin.spec file.

%build
CFLAGS="$RPM_OPT_FLAGS"; export CFLAGS
%{__perl} Makefile.PL PREFIX=%{_prefix} SYSCONFDIR=%{_sysconfdir} 
DESTDIR=$RPM_BUILD_ROOT < /dev/null
%{__make}

Checking if your kit is complete...
Looks good
'ENABLE_SSL' is not a known MakeMaker parameter name.
'SYSCONFDIR' is not a known MakeMaker parameter name.
Writing Makefile for Mail::SpamAssassin
Makefile written by ExtUtils::MakeMaker 6.42
+ /usr/bin/make 'OPTIMIZE=-O2 -g' -j3

spamassassin-3.2.5 does not complain about ENABLE_SSL or SYSCONFDIR in 
MakeMaker.  What changed?  Do we need to adapt?

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 07/03/2009 10:37 PM, Matt Kettler wrote:
> The public alpha release was announced yesterday on the users mailing list:
>
> http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E

I'm having trouble getting it to run on Fedora 11.

[root@newcaprica spamassassin]# sa-update
config: no configuration text or files found! do you need to run 
'sa-update'?
check: no loaded plugin implements 'check_main': cannot scan!
Check the necessary '.pre' files are in the config directory.

*** spamassassin-3.2.5 ***

[root@newcaprica ~]# cd /etc/mail/spamassassin/
[root@newcaprica spamassassin]# ls
init.pre  local.cf  sa-update-keys  spamassassin-default.rc 
spamassassin-helper.sh  spamassassin-spamc.rc  v310.pre  v312.pre  v320.pre

*** spamassassin-3.3.0-alpha1 ***

[root@newcaprica ~]# cd /etc/mail/spamassassin/
[root@newcaprica spamassassin]# ls
local.cf  sa-update-keys  spamassassin-default.rc 
spamassassin-helper.sh  spamassassin-spamc.rc

All of the *.pre files are no longer being installed into our RPM.  It 
seems to pass the test suite though.

All tests successful.
Files=151, Tests=1938, 173 wallclock secs ( 1.05 usr  0.39 sys + 67.07 
cusr 13.81 csys = 82.32 CPU)
Result: PASS

Still looking...

Warren Togami
wtogami@redhat.com

Re: 3.3.0 plans

Posted by Matt Kettler <mk...@verizon.net>.
Warren Togami wrote:
> On 06/29/2009 11:59 AM, Justin Mason wrote:
>> On Mon, Jun 29, 2009 at 16:27, Warren Togami<wt...@redhat.com>  wrote:
>>> On 06/29/2009 07:44 AM, Justin Mason wrote:
>>>> How's about I cut an alpha at the end of this week?
>>>>
>>> Why end of the week if nothing on the list is blockers?
>>
>> ok ok.  good point ;)
>>
>> Let's give it 3 days to garner some comments and possibly close out a
>> few of those P1s and P2s.  Wednesday evening...
>>
>> --j.
>
> How is this going?
>
> Warren
>
>
The public alpha release was announced yesterday on the users mailing list:

http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C6c399e450907021522k1678f0ffn454a1e670f064b40@mail.gmail.com%3E



Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 06/29/2009 11:59 AM, Justin Mason wrote:
> On Mon, Jun 29, 2009 at 16:27, Warren Togami<wt...@redhat.com>  wrote:
>> On 06/29/2009 07:44 AM, Justin Mason wrote:
>>> How's about I cut an alpha at the end of this week?
>>>
>> Why end of the week if nothing on the list is blockers?
>
> ok ok.  good point ;)
>
> Let's give it 3 days to garner some comments and possibly close out a
> few of those P1s and P2s.  Wednesday evening...
>
> --j.

How is this going?

Warren

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Mon, Jun 29, 2009 at 16:27, Warren Togami<wt...@redhat.com> wrote:
> On 06/29/2009 07:44 AM, Justin Mason wrote:
>>
>> How's about I cut an alpha at the end of this week?
>>
>
> Why end of the week if nothing on the list is blockers?

ok ok.  good point ;)

Let's give it 3 days to garner some comments and possibly close out a
few of those P1s and P2s.  Wednesday evening...

--j.

Re: 3.3.0 plans

Posted by Warren Togami <wt...@redhat.com>.
On 06/29/2009 07:44 AM, Justin Mason wrote:
> How's about I cut an alpha at the end of this week?
>

Why end of the week if nothing on the list is blockers?

Warren

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
ok!  Here's what I see in bugzilla right now:

 ID  	 Sev  	 Pri  	 OS  	 Assignee  	 Status  	 Resolution  	 Summary
6077 	maj 	P1 	All 	dev@spamassassin.apache.org 	NEW 		fix failing tests
6131 	maj 	P1 	All 	dev@spamassassin.apache.org 	NEW 		Makefile.PL is
doing evil things to detect DESTDIR
6139 	maj 	P1 	All 	dev@spamassassin.apache.org 	NEW 		remove
"rulesrc" external from SVN tree
5553 	nor 	P1 	All 	dev@spamassassin.apache.org 	ASSI
		MIME_BASE64_TEXT does not handle charset properly
5871 	enh 	P1 	All 	dev@spamassassin.apache.org 	REOP 		need docs for
new '--filter-retries' spamc switch

[so those are the 5 P1s.  these are all things that should be done
before a release, but none of them are blockers IMO.]

4949 	nor 	P2 	Free 	dev@spamassassin.apache.org 	NEW 		spamd shutting
down when unable to fork new processes
5591 	nor 	P2 	Sola 	dev@spamassassin.apache.org 	NEW 		make test
fails at spamd_hup test on Solaris 9, 10
6132 	enh 	P2 	All 	dev@spamassassin.apache.org 	REOP 		FreeMail plugin

[would be nice to get done but again not blockers.]

everything else on the 3.3.0 milestone can be pushed off if nobody
gets the tuits to do them.
I think we could conceivably start the 3.3.0 release process soon....
paging Warren ;)

How's about I cut an alpha at the end of this week?

--j.


On Wed, Jun 24, 2009 at 23:00, Justin Mason<jm...@jmason.org> wrote:
> On Wed, Jun 24, 2009 at 21:37, Justin Mason<jm...@jmason.org> wrote:
>> On Wed, Jun 24, 2009 at 21:21, Theo Van Dinter<fe...@kluge.net> wrote:
>>> fwiw, the process used to be:
>>> - beta releases to get things stabilized
>>> - use a beta release to do mass-check runs
>>> - generate scores with mass-check data and submit to svn
>>
>> I think we may be able to simplify that, now that Daryl's system is
>> generating scores weekly...
>>
>> Also one hard part that we need to do is finish the "no rules in main
>> tarball" work item.
>
> which I've just done ;)
>
> is there anything else that we should sort out before an alpha is viable?
>
> --j.
>
>>> - rc releases to get wider testing w/ scores
>>> - release after rc appear to work

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jun 24, 2009 at 21:37, Justin Mason<jm...@jmason.org> wrote:
> On Wed, Jun 24, 2009 at 21:21, Theo Van Dinter<fe...@kluge.net> wrote:
>> fwiw, the process used to be:
>> - beta releases to get things stabilized
>> - use a beta release to do mass-check runs
>> - generate scores with mass-check data and submit to svn
>
> I think we may be able to simplify that, now that Daryl's system is
> generating scores weekly...
>
> Also one hard part that we need to do is finish the "no rules in main
> tarball" work item.

which I've just done ;)

is there anything else that we should sort out before an alpha is viable?

--j.

>> - rc releases to get wider testing w/ scores
>> - release after rc appear to work
>>
>>
>>
>> On Wed, Jun 24, 2009 at 2:11 PM, Quanah Gibson-Mount<qu...@zimbra.com> wrote:
>>> --On Wednesday, June 24, 2009 5:28 PM +0200 Mark Martinec
>>> <Ma...@ijs.si> wrote:
>>>
>>>
>>>
>>>> On my part I've spent less time lately on SpamAssassin then
>>>> I would like. Getting the amavis release out, preparing for
>>>> a conference, and then there will be a vacation time for me,
>>>> so I won't be of much help until the end of July.
>>>>
>>>> I wonder if there's anything we could do without too much
>>>> trouble to let more people start using the 3.3 code from CVS.
>>>> I suppose there are still nightly tarball builds? (I haven't
>>>> checked). Perhaps just giving an encouraging hint every now
>>>> and then on a mailing list could be a good start.
>>>
>>> Maybe a public alpha or beta release?  So folks know it isn't official, but
>>> can start testing it out.
>>>
>>> --Quanah
>>>
>>> --
>>>
>>> Quanah Gibson-Mount
>>> Principal Software Engineer
>>> Zimbra, Inc
>>> --------------------
>>> Zimbra ::  the leader in open source messaging and collaboration
>>>
>>
>>
>

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jun 24, 2009 at 21:21, Theo Van Dinter<fe...@kluge.net> wrote:
> fwiw, the process used to be:
> - beta releases to get things stabilized
> - use a beta release to do mass-check runs
> - generate scores with mass-check data and submit to svn

I think we may be able to simplify that, now that Daryl's system is
generating scores weekly...

Also one hard part that we need to do is finish the "no rules in main
tarball" work item.

> - rc releases to get wider testing w/ scores
> - release after rc appear to work
>
>
>
> On Wed, Jun 24, 2009 at 2:11 PM, Quanah Gibson-Mount<qu...@zimbra.com> wrote:
>> --On Wednesday, June 24, 2009 5:28 PM +0200 Mark Martinec
>> <Ma...@ijs.si> wrote:
>>
>>
>>
>>> On my part I've spent less time lately on SpamAssassin then
>>> I would like. Getting the amavis release out, preparing for
>>> a conference, and then there will be a vacation time for me,
>>> so I won't be of much help until the end of July.
>>>
>>> I wonder if there's anything we could do without too much
>>> trouble to let more people start using the 3.3 code from CVS.
>>> I suppose there are still nightly tarball builds? (I haven't
>>> checked). Perhaps just giving an encouraging hint every now
>>> and then on a mailing list could be a good start.
>>
>> Maybe a public alpha or beta release?  So folks know it isn't official, but
>> can start testing it out.
>>
>> --Quanah
>>
>> --
>>
>> Quanah Gibson-Mount
>> Principal Software Engineer
>> Zimbra, Inc
>> --------------------
>> Zimbra ::  the leader in open source messaging and collaboration
>>
>
>

Re: 3.3.0 plans

Posted by Theo Van Dinter <fe...@kluge.net>.
fwiw, the process used to be:
- beta releases to get things stabilized
- use a beta release to do mass-check runs
- generate scores with mass-check data and submit to svn
- rc releases to get wider testing w/ scores
- release after rc appear to work



On Wed, Jun 24, 2009 at 2:11 PM, Quanah Gibson-Mount<qu...@zimbra.com> wrote:
> --On Wednesday, June 24, 2009 5:28 PM +0200 Mark Martinec
> <Ma...@ijs.si> wrote:
>
>
>
>> On my part I've spent less time lately on SpamAssassin then
>> I would like. Getting the amavis release out, preparing for
>> a conference, and then there will be a vacation time for me,
>> so I won't be of much help until the end of July.
>>
>> I wonder if there's anything we could do without too much
>> trouble to let more people start using the 3.3 code from CVS.
>> I suppose there are still nightly tarball builds? (I haven't
>> checked). Perhaps just giving an encouraging hint every now
>> and then on a mailing list could be a good start.
>
> Maybe a public alpha or beta release?  So folks know it isn't official, but
> can start testing it out.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>

Re: 3.3.0 plans

Posted by Justin Mason <jm...@jmason.org>.
On Wed, Jun 24, 2009 at 19:11, Quanah Gibson-Mount<qu...@zimbra.com> wrote:
> --On Wednesday, June 24, 2009 5:28 PM +0200 Mark Martinec
> <Ma...@ijs.si> wrote:
>
>> On my part I've spent less time lately on SpamAssassin then
>> I would like. Getting the amavis release out, preparing for
>> a conference, and then there will be a vacation time for me,
>> so I won't be of much help until the end of July.
>>
>> I wonder if there's anything we could do without too much
>> trouble to let more people start using the 3.3 code from CVS.
>> I suppose there are still nightly tarball builds? (I haven't
>> checked). Perhaps just giving an encouraging hint every now
>> and then on a mailing list could be a good start.
>
> Maybe a public alpha or beta release?  So folks know it isn't official, but
> can start testing it out.

A public alpha might be a good option.  The main stuff we need to do
after that would be procedural changes and score generation.

--j.

> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>
>

Re: 3.3.0 plans

Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On Wednesday, June 24, 2009 5:28 PM +0200 Mark Martinec 
<Ma...@ijs.si> wrote:



> On my part I've spent less time lately on SpamAssassin then
> I would like. Getting the amavis release out, preparing for
> a conference, and then there will be a vacation time for me,
> so I won't be of much help until the end of July.
>
> I wonder if there's anything we could do without too much
> trouble to let more people start using the 3.3 code from CVS.
> I suppose there are still nightly tarball builds? (I haven't
> checked). Perhaps just giving an encouraging hint every now
> and then on a mailing list could be a good start.

Maybe a public alpha or beta release?  So folks know it isn't official, but 
can start testing it out.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Re: 3.3.0 plans

Posted by Mark Martinec <Ma...@ijs.si>.
Sorry for my late response, and bringing the topic back to the list
(with some quotes omitted).

Warren Togami writes:
> Might it be feasible to get 3.3.0 out sometime during the Fedora 12 dev
> cycle?  It seems there is maybe 2-3 months.  A fresh spamassassin making
> this release might possibly be particularly more important than other
> releases for unnamed reasons...

Justin writes:
> It would be quite possible to do this, given a sufficiently-dedicated
> release guy pushing it.  It takes about 2 months to get through
> mass-checks, generate good scores, etc. Unfortunately, I'm out for this
> job, as child #2 is about to be born any day now ;)
>
> BTW in the short term, if ppl want to help 3.3.0 release plans, I suggest
> trying out the SVN trunk code as "dogfood".  I've been doing this for the
> last couple of years with very good results; I can't recall the last time
> I had to restart my spamd, for example, or spotted an FP...

I've also been running a fresh 3.3 in production at our site for more
than a year now, mostly because it provides bug fixes and some new
features or workarounds that I need. For example with a Perl upgrade
to 5.8.9 (and later to 5.10.0) on FreeBSD ports the old 3.2.5 just
couldn't survive any longer without crashing due to exceeded stack
size while compiling our set of rules (a perl bug).

I can confirm that 3.3 fares at least as well as 3.2.5, and in
many ways better. I do monitor for possible glitches, but there
just aren't any (new ones that is, that would not also be in 3.2.5).
I may also add that the more recent versions of amavisd-new are
happier with 3.3 than with 3.2.5, as this enables some nice SA
functionality (like SA timing breakdown reports, DKIM checking
of long mail messages).

The trouble with only a handful of sites running the new code is
that not all features are exercised, and not all setups tested.

Then there is a concern that some of the fixes for old bug reports
would still be nice to get into a 3.3 before a release, and some
nice features added/finished. Given the current progress trends
this is unfortunately just stretching time to a release, rising
a feeling that "it just isn't ripe yet". We might consider just
setting our goal/expectations closer to ground, and come out with
what we have.

> I'm pretty sure this won't be achievable in that timeframe if I'm
> driving the release process [...] while I'm busy running after babies ;)
> guys, I can totally provide advice/guidance as to how to go about
> this, if you feel up to it.
>
> basically this wiki page describes the basic idea of how to put
> together a new x.y.0 release:
> http://wiki.apache.org/spamassassin/ReleasePolicy
>
> the biggest task is working through this:
> http://wiki.apache.org/spamassassin/RescoreMassCheck

On my part I've spent less time lately on SpamAssassin then
I would like. Getting the amavis release out, preparing for
a conference, and then there will be a vacation time for me,
so I won't be of much help until the end of July.

I wonder if there's anything we could do without too much
trouble to let more people start using the 3.3 code from CVS.
I suppose there are still nightly tarball builds? (I haven't
checked). Perhaps just giving an encouraging hint every now
and then on a mailing list could be a good start.

  Mark