Bug 3388

Needed to go with the new masses/ stuff

I propose that this (and possibly 2853) get moved to 3.1 unless the code is 
ready to go now.  I really don't think these are a 3.0 blocker, it'd just be 
nice to have.

it'd be really really nice to have. It'll have major effect on the usability of
3.0.0 after 3 months or so.

I don't think it's a really tough change, but I agree we're running a little late.

Perhaps we could comprimise and move it to 3.0.1?

Subject: Re:  Fix perceptron.c to allow for run-time read of logs

On Sat, May 22, 2004 at 02:21:07PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> it'd be really really nice to have. It'll have major effect on the usability of
> 3.0.0 after 3 months or so.

???  How so?  The perceptron (and everything in masses) is, by in large,
for developers only.  There's nothing in there which is required for
3.0 to run, nor is it even installed by default.  So I don't see how
there'll be an effect on usability.

> Perhaps we could comprimise and move it to 3.0.1?

I don't think the masses directory matters for a release, so don't have
a problem making changes to it through a "stable" release cycle.

My issue for right now is that we're taking forever to get 3.0 out,
and I'm really tempted to say "screw all the open tickets".

Subject: Re:  Fix perceptron.c to allow for run-time read of logs

On Sat, May 22, 2004 at 03:17:36PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> ???  How so?  The perceptron (and everything in masses) is, by in large,
> for developers only.  There's nothing in there which is required for
> 3.0 to run, nor is it even installed by default.  So I don't see how
> there'll be an effect on usability.

We have always known that the effectiveness of SpamAssassin
deteriorates over time between releases. If users are able to generate
their own scores, SpamAssassin will continue to give them very good
hit rates.

In some ways, we're kinda like Debian. We make large releases fairly
infrequently, and users are forced to resort to third parties in order
to meet their needs (for Debian, this is third party backports of
Debian packages). If we distribute scripts that make it easy to make
your own scores, people can do this when their hit rates start
deteriorating and it extends the useful life of SpamAssassin.

My "3 month" figure is a bit of an exaggeration.

Subject: Re:  Fix perceptron.c to allow for run-time read of logs

On Sat, May 22, 2004 at 03:47:19PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Debian packages). If we distribute scripts that make it easy to make
> your own scores, people can do this when their hit rates start
> deteriorating and it extends the useful life of SpamAssassin.

Ok, so I think we agree that this doesn't need to hold up the 3.0 release,
but it'd be nice to get done.  Anyone have an issue if we punted the
ticket to the 3.1 queue?  If the code is ready earlier, we can consider
it for a 3.0.x release...  (imo, the masses directory is available for
enhancement during a "stable" release cycle, since any form of score
generation is technically "development"...)

Subject: Re:  Fix perceptron.c to allow for run-time read of logs

> Ok, so I think we agree that this doesn't need to hold up the 3.0 release,
> but it'd be nice to get done.

Fair enough. I'll agree to that.

ok, moving to 3.1 queue for now.

move bug to Future milestone (previously set to Future -- I hope)

Closing ancient stale bug.