On Thu, Jun 29, 2006 at 10:57:18AM +0100, Justin Mason wrote: > - (1) it breaks people running "sa-update" on an svn trunk build, since > now the svn trunk update set includes references to an EvalTests.pm > function that won't exist in older revs.
Irrelevent IMO. If one is running a dev version, there will be issues like this that have to be accepted. sa-update is meant to work for released versions, not dev versions. > - (2) I think we wanted to reduce the ongoing use of EvalTests.pm in > general, as a goal, iirc. That depends who you ask apparently (more below). On Thu, Jun 29, 2006 at 04:21:54AM -0700, Loren Wilton wrote: > How hard would it be to make an evaltests plugin that literally contains > whatever rules are currently in evaltests.pm? So ... Last year at ApacheCon US a bunch of us had a discussion about this, and generally decided it would be best to get rid of EvalTests and move the functionality into plugins. So I then spent 2 or 3 days worth of time going through and doing that, ending up with: http://svn.apache.org/repos/asf/spamassassin/branches/tvd-evaltoplugin/ (now horribly out of date, btw.) Everything looked good, except that certain people started complaining about the idea, the implementation, and generally were against getting rid of EvalTests. It didn't really move forward from there, so that was the end of that. > Yes, this is a kludge. But if it can be done in 10 minutes vs 10 months or > even 10 days to split evaltests into 150 silly separate plugins, one for > each rule, then it might be the right thing to do. It could be broken up > more later once it was out of the main project body. I thought a plugin per rule would be really annoying, so I split it up into (iirc) 5 or 6 loosely related plugins (whitelist/blacklist, header rules, body rules, etc.) On Thu, Jun 29, 2006 at 12:26:01PM +0100, Justin Mason wrote: > well, I'm not suggesting that we kill off the *current* contents of > EvalTests. instead we can leave those there -- but future additions > should be kept out of that file if possible. I'm +1 to killing off EvalTests, btw. I argued about this before, so I don't want to fully rehash it again -- see the thread: http://www.nabble.com/forum/ViewPost.jtp?post=2124116 I'd be willing to expend some effort doing this process again (only if we all agree (again?) ahead of time to do it). The main time suck now is to merge the changes in trunk since the branch, which will likely be a few hours worth of work. > As to the ease of moving the current contents into a new plugin .pm. > Actually this wouldn't be so easy, since people using a pre-move > copy of EvalTests.pm would then wind up with duplicated code; one > function in EvalTests.pm, and another one colliding with it from > the plugin .pm. Again, irrelevent IMO. If people are using the development version, they need to accept that sometimes things will blow up and that they will need to keep up with changes. It's a development version for a reason. -- Randomly Generated Tagline: "The cardinal rule at our school is simple. No shooting at teachers. If you have to shoot a gun, shoot it at a student or an administrator." - "Word Smart II", from Princeton Review Pub.
pgpEgeLDWymYC.pgp
Description: PGP signature
