Mailing List Archive: SpamAssassin: devel

3.3.0 plans

Index | Next | Previous | View Threaded

jm at jmason

Mar 14, 2008, 8:36 AM

Post #1 of 13 (455 views)
Permalink

3.3.0 plans

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

Also, 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?

--j.

quanah at zimbra

Mar 14, 2008, 6:53 PM

Post #2 of 13 (436 views)
Permalink

Re: 3.3.0 plans [In reply to]

--On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
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:

<http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
please. :)

--

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

jm at jmason

Mar 15, 2008, 3:43 AM

Post #3 of 13 (435 views)
Permalink

Re: 3.3.0 plans [In reply to]

Quanah Gibson-Mount writes:
> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
> 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:
>
> <http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
> please. :)

unfortunately, there's no patch there, and it appears that BerkeleyDB
doesn't support upgrading of .db files anyway. unlikely to get in,
given that!

--j.

wtogami at redhat

May 16, 2008, 8:28 AM

Post #4 of 13 (383 views)
Permalink

Re: 3.3.0 plans [In reply to]

Justin Mason wrote:
> Quanah Gibson-Mount writes:
>> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
>> 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:
>> <http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
>> please. :)
>
> unfortunately, there's no patch there, and it appears that BerkeleyDB
> doesn't support upgrading of .db files anyway. unlikely to get in,
> given that!
>
> --j.

How are the 3.3.0 plans coming along?

Warren

jm at jmason

May 16, 2008, 8:38 AM

Post #5 of 13 (383 views)
Permalink

Re: 3.3.0 plans [In reply to]

Warren Togami writes:
> Justin Mason wrote:
> > Quanah Gibson-Mount writes:
> >> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
> >> 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:
> >> <http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
> >> please. :)
> >
> > unfortunately, there's no patch there, and it appears that BerkeleyDB
> > doesn't support upgrading of .db files anyway. unlikely to get in,
> > given that!
>
> How are the 3.3.0 plans coming along?

Hmm. things have been pretty quiet -- I think we're all a bit distracted
by other, non-SpamAssassin-related stuff, unfortunately.

I've been meaning to try to push it along, the big work items are:

- fixing the distribution process to work without rules in the dist
tarball (since we'll be moving to a model where with distribute
without rules and they're downloaded by the admin on install).

- generating automated daily scores with Daryl. this is kind of complex
since it relies on having good rule-QA data coming in with the
"reuse=yes" flag set, and I'm not sure what our current status is
there.

I don't see anything else remaining in the 3.3.0 queue that are necessary
as much as those two.

--j.

wtogami at redhat

May 16, 2008, 8:47 AM

Post #6 of 13 (383 views)
Permalink

Re: 3.3.0 plans [In reply to]

Justin Mason wrote:
> Warren Togami writes:
>> Justin Mason wrote:
>>> Quanah Gibson-Mount writes:
>>>> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
>>>> 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:
>>>> <http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
>>>> please. :)
>>> unfortunately, there's no patch there, and it appears that BerkeleyDB
>>> doesn't support upgrading of .db files anyway. unlikely to get in,
>>> given that!
>> How are the 3.3.0 plans coming along?
>
> Hmm. things have been pretty quiet -- I think we're all a bit distracted
> by other, non-SpamAssassin-related stuff, unfortunately.
>
> I've been meaning to try to push it along, the big work items are:
>
> - fixing the distribution process to work without rules in the dist
> tarball (since we'll be moving to a model where with distribute
> without rules and they're downloaded by the admin on install).
>
> - generating automated daily scores with Daryl. this is kind of complex
> since it relies on having good rule-QA data coming in with the
> "reuse=yes" flag set, and I'm not sure what our current status is
> there.
>

Should 5899 be fixed before 3.3.0? It seems to be a potential cause of
upgrade confusion.

Warren

jm at jmason

May 16, 2008, 8:56 AM

Post #7 of 13 (381 views)
Permalink

Re: 3.3.0 plans [In reply to]

Warren Togami writes:
> Justin Mason wrote:
> > Warren Togami writes:
> >> Justin Mason wrote:
> >>> Quanah Gibson-Mount writes:
> >>>> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm[at]jmason.org>
> >>>> 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:
> >>>> <http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4416> please please
> >>>> please. :)
> >>> unfortunately, there's no patch there, and it appears that BerkeleyDB
> >>> doesn't support upgrading of .db files anyway. unlikely to get in,
> >>> given that!
> >> How are the 3.3.0 plans coming along?
> >
> > Hmm. things have been pretty quiet -- I think we're all a bit distracted
> > by other, non-SpamAssassin-related stuff, unfortunately.
> >
> > I've been meaning to try to push it along, the big work items are:
> >
> > - fixing the distribution process to work without rules in the dist
> > tarball (since we'll be moving to a model where with distribute
> > without rules and they're downloaded by the admin on install).
> >
> > - generating automated daily scores with Daryl. this is kind of complex
> > since it relies on having good rule-QA data coming in with the
> > "reuse=yes" flag set, and I'm not sure what our current status is
> > there.
> >
>
> Should 5899 be fixed before 3.3.0? It seems to be a potential cause of
> upgrade confusion.

yes.

matthias at leisi

May 19, 2008, 3:09 AM

Post #8 of 13 (364 views)
Permalink

Re: 3.3.0 plans [In reply to]

> - fixing the distribution process to work without rules in the dist
> tarball (since we'll be moving to a model where with distribute
> without rules and they're downloaded by the admin on install).

The longer I think about it, the less convinced I am that it is a good idea.

In environments requiring strict change control or that are otherwise
paranoid in terms of security, (direct) online updates are usually not
desired (or not possible, because eg the firewall concept forbids
mailservers from doing HTTP requests).

Thus actually *requiring* online update would make deployment in such
environments more complex (it would eg require repackaging *with* the
rules prior to deployment).

The same environments would also be rather reluctant to allow direct
online updates without at least some form of sanity check (maybe not only
lint, but also some messages being checked).

Although I'd like to see some clearer structure in how rules and rules
updates (of different sources) are handled, I suggest that some basic
ruleset ("rules du jour at the day of packing a release" or something
similar) be included with the tarball.

-- Matthias

jm at jmason

May 19, 2008, 9:48 AM

Post #9 of 13 (359 views)
Permalink

Re: 3.3.0 plans [In reply to]

Matthias Leisi writes:
> > - fixing the distribution process to work without rules in the dist
> > tarball (since we'll be moving to a model where with distribute
> > without rules and they're downloaded by the admin on install).
>
> The longer I think about it, the less convinced I am that it is a good idea.
>
> In environments requiring strict change control or that are otherwise
> paranoid in terms of security, (direct) online updates are usually not
> desired (or not possible, because eg the firewall concept forbids
> mailservers from doing HTTP requests).
>
> Thus actually *requiring* online update would make deployment in such
> environments more complex (it would eg require repackaging *with* the
> rules prior to deployment).
>
> The same environments would also be rather reluctant to allow direct
> online updates without at least some form of sanity check (maybe not only
> lint, but also some messages being checked).
>
> Although I'd like to see some clearer structure in how rules and rules
> updates (of different sources) are handled, I suggest that some basic
> ruleset ("rules du jour at the day of packing a release" or something
> similar) be included with the tarball.

hi Matthias --

if you check the bug (can't recall the number right now), there's plans to
make a tarball available of _just_ the rules, alongside the distro at
release time. That way, that kind of users can dl the tarball and
install it using "sa-update --install SpamAssassin-rules-349584.tgz" (or
whatever).

Does that work?

--j.

matthias at leisi

May 19, 2008, 11:55 AM

Post #10 of 13 (358 views)
Permalink

Re: 3.3.0 plans [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Mason schrieb:

| if you check the bug (can't recall the number right now), there's plans to
| make a tarball available of _just_ the rules, alongside the distro at
| release time. That way, that kind of users can dl the tarball and
| install it using "sa-update --install SpamAssassin-rules-349584.tgz" (or
| whatever).

How would a typical distro handle this (or how are they thought to
handle it)? Pack the rules tarball at date of packaging? That should be
acceptable for most, as this would be basically the same as today (two
tarballs instead of one, but from the same source).

A rules package from the same source as the app package is definitely
acceptable. Would / should updated rules packages be made available
through the same channels as the initial one? (IMO, this *should* be
done - through distros, CPAN, ...).

- -- Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFIMc0nxbHw2nyi/okRAgIBAJ92gIAuBvsV51KucUMIrvgmpWEQPACeLHIQ
YlWoXASfBRA9/FhRM5cdOgk=
=ZjPM
-----END PGP SIGNATURE-----

jm at jmason

May 19, 2008, 12:35 PM

Post #11 of 13 (356 views)
Permalink

Re: 3.3.0 plans [In reply to]

Matthias Leisi writes:
> Justin Mason schrieb:
>
> | if you check the bug (can't recall the number right now), there's plans to
> | make a tarball available of _just_ the rules, alongside the distro at
> | release time. That way, that kind of users can dl the tarball and
> | install it using "sa-update --install SpamAssassin-rules-349584.tgz" (or
> | whatever).
>
> How would a typical distro handle this (or how are they thought to
> handle it)? Pack the rules tarball at date of packaging? That should be
> acceptable for most, as this would be basically the same as today (two
> tarballs instead of one, but from the same source).

Yes, that's what I was thinking.

> A rules package from the same source as the app package is definitely
> acceptable. Would / should updated rules packages be made available
> through the same channels as the initial one? (IMO, this *should* be
> done - through distros, CPAN, ...).

I'm fine with doing that ;)

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5752 is the bug.
could you add that recommendation there?

--j.

wtogami at redhat

Aug 25, 2008, 4:50 PM

Post #12 of 13 (244 views)
Permalink

Re: 3.3.0 plans [In reply to]

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?

Warren Togami
wtogami[at]redhat.com

jm at jmason

Aug 28, 2008, 3:47 AM

Post #13 of 13 (206 views)
Permalink

Re: 3.3.0 plans [In reply to]

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.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com