hey, For what it's worth, I am still +1 on the 'tvd-evaltoplugin' approach.
(I'm +0 on whether it should be 'all in one big LegacyEvalTestsPlugin.pm' or 'split into multiple little .pms', though; I don't really mind either way.) By the way, looking back through that thread (<http://marc.theaimsgroup.com/?l=spamassassin-devel&m=113581166500095&w=2>), it's worth noting that some users of SpamAssassin *would* find it useful to be able to turn off the existing eval test set: namely people who are using the SpamAssassin engine, without using the basic SpamAssassin ruleset. For them, EvalTests.pm is all dead code. And finally -- regardless of how the 'tvd-evaltoplugin' approach is judged, the approach of putting *new* eval tests into plugin .pms can be considered a quite separate issue, in my opinion. --j. Theo Van Dinter writes: > 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.
