Re: 3.3.0 plans

[Justin Mason <jm...@jmason.org>]

Warren Togami writes:
> Justin Mason wrote:
> > Quanah Gibson-Mount writes:
> >> --On Friday, March 14, 2008 3:36 PM +0000 Justin Mason <jm...@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.

Re: 3.3.0 plans

[Matthias Leisi <ma...@leisi.net>]

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

Re: 3.3.0 plans

[Warren Togami <wt...@redhat.com>]

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