You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Simon Byrnand <si...@igrin.co.nz> on 2005/01/07 01:27:57 UTC
annoying changes in 3.0
Hi All,
Just setting up SA 3.0.2 on a test server (to work towards upgrading our
main server that runs 2.64) and have discovered a change that might seem
innocent to the designers, but which is a PITA for us.
According to UPGRADE:
- The "rewrite_subject" and "subject_tag" configuration options were
deprecated and are now removed. Instead, using "rewrite_header Subject
[your desired setting]". e.g.
rewrite_subject 1
subject_tag ****SPAM(_SCORE_)****
becomes
rewrite_header Subject ****SPAM(_SCORE_)****
What was the logic behind this unnecessary change ?
In our case we have a global subject_tag setting in
/etc/mail/spamassassin/local.cf but the per user .prefs files contain
rewrite_subject 1 (or 0) depending on what the user selects through a web
gui. (As one of a limited set of options they are allowed to configure)
Now with 3.0, as far as I can see there is no longer a way to configure the
actual subject string globally in the local.cf, but allow it to be turned
on and off from a per user .prefs file ? Or have I missed something ? :(
Looks like I'll have no choice but to remove the option from the web gui
altogether, as having the actual subject string in every single .prefs file
doesn't make changing it in future very practical...
Regards,
Simon
Re: annoying changes in 3.0
Posted by Rick Macdougall <ri...@nougen.com>.
Simon Byrnand wrote:
> Hi All,
>
> Just setting up SA 3.0.2 on a test server (to work towards upgrading our
> main server that runs 2.64) and have discovered a change that might seem
> innocent to the designers, but which is a PITA for us.
>
> According to UPGRADE:
>
> - The "rewrite_subject" and "subject_tag" configuration options were
> deprecated and are now removed. Instead, using "rewrite_header Subject
> [your desired setting]". e.g.
>
> rewrite_subject 1
> subject_tag ****SPAM(_SCORE_)****
>
> becomes
>
> rewrite_header Subject ****SPAM(_SCORE_)****
>
>
> What was the logic behind this unnecessary change ?
>
> In our case we have a global subject_tag setting in
> /etc/mail/spamassassin/local.cf but the per user .prefs files contain
> rewrite_subject 1 (or 0) depending on what the user selects through a
> web gui. (As one of a limited set of options they are allowed to configure)
>
> Now with 3.0, as far as I can see there is no longer a way to configure
> the actual subject string globally in the local.cf, but allow it to be
> turned on and off from a per user .prefs file ? Or have I missed
> something ? :(
Hi,
rewrite_header Subject
Will turn off the rewrite (ie setting it to nothing.)
Regards,
Rick
Re: annoying changes in 3.0
Posted by David Brodbeck <gu...@gull.us>.
Matt Kettler wrote:
>> Having overlap for at least one revision allows seamless in-place
>> upgrade.
>> Having zero does not.
>
>
> No Dan, it does not allow a seamless in-place upgrade, unless you only
> ever upgrade once.
>
> If SA version N+1 supports commands from N, and your config file is in
> version N syntax, you can upgrade seamlessly, but as soon as N+2 comes
> out, you won't be able to upgrade seamlessly anymore.
Right, but if N+1 supports both syntaxes, you can upgrade to N+1, then
change your config files at your leisure before upgradign to N+2. If N
doesn't support the new syntax, and N+1 doesn't support the old syntax,
your only choice is to take down the system, change the files, then
bring it up with the new version.
Re: annoying changes in 3.0
Posted by Matt Kettler <mk...@evi-inc.com>.
At 02:28 AM 1/12/2005, Dan Hollis wrote:
> > But also to be fair, even though you give people N releases with both
> > features available to do the conversion, there are going to be some
> > significant number of users that simply won't do the conversion until they
> > are forced to, even though they had 3 releases in which they could have
> done
> > it.
>
>Having overlap for at least one revision allows seamless in-place upgrade.
>Having zero does not.
No Dan, it does not allow a seamless in-place upgrade, unless you only ever
upgrade once.
If SA version N+1 supports commands from N, and your config file is in
version N syntax, you can upgrade seamlessly, but as soon as N+2 comes out,
you won't be able to upgrade seamlessly anymore. If you're at N+1's syntax,
you can upgrade to N+2, but as soon as N+3 comes out, you've got to edit..
And so on.
Unless there's some additional detail I'm missing, like an expectation that
SA will actually fix your config files for you, I don't see how this offers
seamless upgrades except in the short term.
Re: annoying changes in 3.0
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, January 11, 2005 9:36 PM -0800 Loren Wilton
<lw...@earthlink.net> wrote:
> But the trick here is that at least one or more releases will contain both
> features. This is different than saying "feature X will be replaced at
> the next major release. We'll tell you what to use in its place in the
> release announcement for the next major release."
Anyone following the betas would have seen this coming for a long time. And
anyone who considers any piece of software to be mission-critical had
better be following betas. There was a long cycle of release candidates
when an admin could check for site issues before the release went gold.
That's the whole point of having release candidates. The developers can't
foresee every possible variation in how people use their product.
Re: annoying changes in 3.0
Posted by Dan Hollis <go...@anime.net>.
On Tue, 11 Jan 2005, Loren Wilton wrote:
> But also to be fair, even though you give people N releases with both
> features available to do the conversion, there are going to be some
> significant number of users that simply won't do the conversion until they
> are forced to, even though they had 3 releases in which they could have done
> it.
Having overlap for at least one revision allows seamless in-place upgrade.
Having zero does not.
-Dan
Re: annoying changes in 3.0
Posted by Loren Wilton <lw...@earthlink.net>.
> > Once you go that route, you must ALWAYS go that route, for every change,
or
> > your efforts are more-or-less pointless. 90% backward compatibility
isn't
> > really much better than 0%. If the user has to edit a config file to
> > upgrade, it's a pain.
Well, of course you don't have to always do it. As in, always maintain the
deprecaited feature.
What you DO have to always do is announce that in release n+ >1 that feature
X will be removed and replaced by feature Y, and that for the n>1
intervening releases BOTH versions of the feature will be supported.
This gives people time to come up on the new version using existing syntax,
and find the problems with the new syntax, if any. If problems exist they
can stay with the old feature, and hopefully in the following release, or a
patch of the current release, the problems with the new feature will be
fixed.
But the trick here is that at least one or more releases will contain both
features. This is different than saying "feature X will be replaced at the
next major release. We'll tell you what to use in its place in the release
announcement for the next major release."
> Making it impossible to upgrade without downtime is bad. With backwards
> compat you allow people to seamlessly upgrade, and migrate their changes
> on a live system. Without it, you force people to shutdown and convert
> their entire system in-place, before upgrading. That's bad.
But also to be fair, even though you give people N releases with both
features available to do the conversion, there are going to be some
significant number of users that simply won't do the conversion until they
are forced to, even though they had 3 releases in which they could have done
it.
Most though will have been more sensible, if the feature decommitment is
promenently makrked in the release notes, and the replacement feature is
also mentioned.
Loren
Re: annoying changes in 3.0
Posted by ChupaCabra <mi...@topstexas.com>.
Ya, I don't get the whole thread. If one wants seamless upgrades and
backwards compat for 10 years one should stick to windows, Solaris, AIX
etc.
Ya, right.
My 1 cent for the week.
Stuart Johnston wrote:
> Dan Hollis wrote:
>
>> On Mon, 10 Jan 2005, Matt Kettler wrote:
>>
>>> <sarcasm>
>>> With over 68% market share, and increasing. Clearly Apache is
>>> hurting badly.
>>> </sarcasm>
>>
>>
>>
>> Apache 2.0 and perl6 adoption is severely stunted because of major
>> backwards compat issues.
>
>
> I'm sorry, I know this is getting OT but why do people keep bringing
> up perl6 adoption? Perl6 hasn't even been released! Besides which,
> Perl6 will include a translator and a Perl5 compatibility mode.
>
> http://dev.perl.org/perl6/faq.html
>
--
Michael H. Collins Admiral, Penguinista Navy
http://linuxlink.com
/"\ ASCII Ribbon Campaign
\ / No HTML/RTF in email
x No Word docs in email
/ \ Respect for open standards
Take your laptop and yell out:
"Can a brother get a ip address?"
Re: annoying changes in 3.0
Posted by Stuart Johnston <st...@ebby.com>.
Dan Hollis wrote:
> On Mon, 10 Jan 2005, Matt Kettler wrote:
>
>><sarcasm>
>>With over 68% market share, and increasing. Clearly Apache is hurting badly.
>></sarcasm>
>
>
> Apache 2.0 and perl6 adoption is severely stunted because of major
> backwards compat issues.
I'm sorry, I know this is getting OT but why do people keep bringing up
perl6 adoption? Perl6 hasn't even been released! Besides which, Perl6
will include a translator and a Perl5 compatibility mode.
http://dev.perl.org/perl6/faq.html
Re: annoying changes in 3.0
Posted by David Brodbeck <gu...@gull.us>.
Dan Hollis wrote:
> On Mon, 10 Jan 2005, Matt Kettler wrote:
> spamassassin could adopt a policy of backwards compat over _one_ revision.
> As it is, the policy is backwards compat over _ZERO_ revisions. This hurts.
This seems to be Samba's policy -- options are deprecated for one major
revision, then removed.
Of course, maybe that's not a great example. The samba.conf file is
full of ugly examples of options that are synonyms -- they do the same
thing, but because they were included once they have to be supported in
every later revision.
Re: annoying changes in 3.0
Posted by Dan Hollis <go...@anime.net>.
On Mon, 10 Jan 2005, Matt Kettler wrote:
> <sarcasm>
> With over 68% market share, and increasing. Clearly Apache is hurting badly.
> </sarcasm>
Apache 2.0 and perl6 adoption is severely stunted because of major
backwards compat issues.
> Once you go that route, you must ALWAYS go that route, for every change, or
> your efforts are more-or-less pointless. 90% backward compatibility isn't
> really much better than 0%. If the user has to edit a config file to
> upgrade, it's a pain.
Making it impossible to upgrade without downtime is bad. With backwards
compat you allow people to seamlessly upgrade, and migrate their changes
on a live system. Without it, you force people to shutdown and convert
their entire system in-place, before upgrading. That's bad.
As for 90% not being better than 0%, that's patently false.
And in the case of 2.64 -> 3.0, there's so few options to support for
backwards compat that it seems silly to argue 90% vs 0%.
> Also, once you decide to support an old option, you must support it for the
> life of your project and never break it, otherwise all you've done is delay
> the problem the user will eventually face, and maybe even make it worse as
> they may become deeper entrenched in outdated syntax.
See below.
> By preserving backward compatibility with subject_tag, you save them from
> having to fix one issue. What about the myriad of others? Should SA 3.0.4
> support all old syntax from 1.0 onward?
>>>>> Nobody's asking for this. <<<<<
You're constructing a strawman.
spamassassin could adopt a policy of backwards compat over _one_ revision.
As it is, the policy is backwards compat over _ZERO_ revisions. This hurts.
-Dan
Re: annoying changes in 3.0
Posted by Matt Kettler <mk...@evi-inc.com>.
At 06:33 PM 1/7/2005, Dan Hollis wrote:
>I guess it's just a difference in philosophy and attitude. On software
>projects I code, I leave backwards compatibility in if possible. Most of
>the time its very simple and never a kludge.
I think our difference is not in philosophy, but in scale. I'm thinking 10
year maintenance timeframes, not the immediate release.
>Again, this philosophy of not supporting backwards compat where it is easy
>to do will just hurt in the long run, like it is hurting php, apache,
>perl, and other projects.
Sidenote.
http://news.netcraft.com/archives/web_server_survey.html
<sarcasm>
With over 68% market share, and increasing. Clearly Apache is hurting badly.
</sarcasm>
I agree that yes, breaking change is sub-optimal.
However, you also need to keep in perspective the costs of backward
compatibility.
Once you go that route, you must ALWAYS go that route, for every change, or
your efforts are more-or-less pointless. 90% backward compatibility isn't
really much better than 0%. If the user has to edit a config file to
upgrade, it's a pain.
Also, once you decide to support an old option, you must support it for the
life of your project and never break it, otherwise all you've done is delay
the problem the user will eventually face, and maybe even make it worse as
they may become deeper entrenched in outdated syntax.
By preserving backward compatibility with subject_tag, you save them from
having to fix one issue. What about the myriad of others? Should SA 3.0.4
support all old syntax from 1.0 onward?
Re: annoying changes in 3.0
Posted by Dan Hollis <go...@anime.net>.
On Fri, 7 Jan 2005, Matt Kettler wrote:
> Hmm, as a user that makes sense. As a programmer, it does not. There's
> nothing like adding "backward compatibility" kludges to add bugs to your
> code. Bugs mean extra work for the developers, work that could be better
> spent fighting spam.
I guess it's just a difference in philosophy and attitude. On software
projects I code, I leave backwards compatibility in if possible. Most of
the time its very simple and never a kludge.
Of course I design my code cleanly so backwards compat is rarely a kludge.
I havent looked at SA code but I would hope it's written well enough that
backwards compat for such a simple option isn't hard. If its too hard,
then it would indicate a problem with the design.
Again, this philosophy of not supporting backwards compat where it is easy
to do will just hurt in the long run, like it is hurting php, apache,
perl, and other projects. Often, not supporting backwards compat for old
stuff means you will not get the critical mass and support required for
users to embrace your new stuff. I hope SA doesnt embrace this philosophy.
You want more users to be using the new versions, not less.
-Dan
Re: annoying changes in 3.0
Posted by Matt Kettler <mk...@evi-inc.com>.
At 12:06 AM 1/7/2005, Dan Hollis wrote:
>I think he meant, why _remove_ the old syntax instead of supporting it _in
>addition to_ the new syntax?
>
>I can't see any good reason not to support old syntax as backwards
>compatibility.
Hmm, as a user that makes sense. As a programmer, it does not. There's
nothing like adding "backward compatibility" kludges to add bugs to your
code. Bugs mean extra work for the developers, work that could be better
spent fighting spam.
You'll find that most OSS packages will sacrifice backward compatibility in
favor of maintainable code and fewer bugs to work around later. I know it's
a bit of a pain, but the general OSS mindset of breaking backward
compatibility is what allows most projects to progress forward.
One or two of these hacks isn't so bad, but once you start down that road
you eventually get bound up by having to maintain hundreds of hacks,
kludges and other garbage in your code that users who still have config
files from 20 years ago need to run their systems.
The "always maintain compatibility" mindset of the windows world is
convenient for users, but really slows down development progress in the
long run, and in some cases completely prevents product improvements. It's
a very bad mindset to be in. Even the windows world is starting to move
away from it by obsoleting older versions of products.
As for breakage, SA has a long history of doing this. This is by far not
the first time.. ie: report_safe.
The Linux kernel does it all the time to their low-level interfaces.
Bind has done it to their zonefile formats.
Re: annoying changes in 3.0
Posted by Dan Hollis <go...@anime.net>.
On Mon, 10 Jan 2005, Simon Byrnand wrote:
> I still havn't even considered looking at Apache 2.0 for example due to the
> major changes and the fact that things such as php weren't available for it
> for some time. (I hate to think what the issues with going to php 5 might be :)
The same issues are hurting acceptance of perl6.
Python isnt much better. All sorts of incompatibilty issues from 1.5 ->
2.0 -> 2.1 -> 2.2 -> 2.3 ... python apps breaking all over the place. No
fun at all.
-Dan
Re: annoying changes in 3.0
Posted by Simon Byrnand <si...@igrin.co.nz>.
At 18:06 7/01/2005, Dan Hollis wrote:
>On Thu, 6 Jan 2005, Matt Kettler wrote:
> > At 07:27 PM 1/6/2005, Simon Byrnand wrote:
> > >- The "rewrite_subject" and "subject_tag" configuration options were
> > > deprecated and are now removed. Instead, using "rewrite_header Subject
> > > [your desired setting]". e.g.
> > > rewrite_subject 1
> > > subject_tag ****SPAM(_SCORE_)****
> > > becomes
> > > rewrite_header Subject ****SPAM(_SCORE_)****
> > >What was the logic behind this unnecessary change ?
> > Flexibility. rewrite_header isn't just capable of rewiting the subject
> > line. It can rewrite other headers too.
>
>I think he meant, why _remove_ the old syntax instead of supporting it _in
>addition to_ the new syntax?
Yes, thats what I meant.
>I can't see any good reason not to support old syntax as backwards
>compatibility.
>
>It would ease migrating to 3.0.x a great deal for many sites to support
>backwards compatibility. Instead, stuff breaks. This is why people are
>so hesitant to move to php5, perl6 etc. spamassassin should not follow
>these examples.
>-Dan
Some changes are an expectation of major new releases of software of
course, but SpamAssassin seems to have had a few gratuitous ones over the
past major couple of releases.... and a few silly little things like
changing sa-learn --rebuild to sa-learn --sync etc.... I'm sure there were
good reasons for it, but it still makes things difficult for people upgrading.
I still havn't even considered looking at Apache 2.0 for example due to the
major changes and the fact that things such as php weren't available for it
for some time. (I hate to think what the issues with going to php 5 might be :)
Regards,
Simon
Re: annoying changes in 3.0
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Thursday, January 06, 2005 9:06 PM -0800 Dan Hollis <go...@anime.net>
wrote:
> It would ease migrating to 3.0.x a great deal for many sites to support
> backwards compatibility. Instead, stuff breaks. This is why people are
> so hesitant to move to php5, perl6 etc. spamassassin should not follow
> these examples.
So why wait until now, long after 3.0 is set in stone, to complain about
this? The whole point of a major version change is to allow breaking
compatibility. (The time spent supporting legacy stuff is time lost for
creating new features.) You know because of that number change that things
are going to break, so you start doing your homework early, before you're
backed into fixing your own stuff to comply.
At this point the horse is out of the barn, so the admins who weren't
paying attention are naturally going to have to play catch-up. It's
important to inform your PHB's that tracking the development of the
products you support is a big part of your job.
Mind you, I'm not arguing against the specific feature. I'm just saying
that if a feature is important to you, don't assume that it's important to
anyone else, or that someone else is watching your back for you.
Re: annoying changes in 3.0
Posted by Dan Hollis <go...@anime.net>.
On Thu, 6 Jan 2005, Matt Kettler wrote:
> At 07:27 PM 1/6/2005, Simon Byrnand wrote:
> >- The "rewrite_subject" and "subject_tag" configuration options were
> > deprecated and are now removed. Instead, using "rewrite_header Subject
> > [your desired setting]". e.g.
> > rewrite_subject 1
> > subject_tag ****SPAM(_SCORE_)****
> > becomes
> > rewrite_header Subject ****SPAM(_SCORE_)****
> >What was the logic behind this unnecessary change ?
> Flexibility. rewrite_header isn't just capable of rewiting the subject
> line. It can rewrite other headers too.
I think he meant, why _remove_ the old syntax instead of supporting it _in
addition to_ the new syntax?
I can't see any good reason not to support old syntax as backwards
compatibility.
It would ease migrating to 3.0.x a great deal for many sites to support
backwards compatibility. Instead, stuff breaks. This is why people are
so hesitant to move to php5, perl6 etc. spamassassin should not follow
these examples.
-Dan
Re: annoying changes in 3.0
Posted by Matt Kettler <mk...@evi-inc.com>.
At 07:27 PM 1/6/2005, Simon Byrnand wrote:
>- The "rewrite_subject" and "subject_tag" configuration options were
> deprecated and are now removed. Instead, using "rewrite_header Subject
> [your desired setting]". e.g.
>
> rewrite_subject 1
> subject_tag ****SPAM(_SCORE_)****
>
> becomes
>
> rewrite_header Subject ****SPAM(_SCORE_)****
>
>
>What was the logic behind this unnecessary change ?
Flexibility. rewrite_header isn't just capable of rewiting the subject
line. It can rewrite other headers too.
>In our case we have a global subject_tag setting in
>/etc/mail/spamassassin/local.cf but the per user .prefs files contain
>rewrite_subject 1 (or 0) depending on what the user selects through a web
>gui. (As one of a limited set of options they are allowed to configure)
>Looks like I'll have no choice but to remove the option from the web gui
>altogether, as having the actual subject string in every single .prefs
>file doesn't make changing it in future very practical...
Hmm, what about modifying the web GUI so the user can specify whatever
subject tag they want? This way it's not up to you to enact (for whatever
reason) some global change of the subject tag, instead each user can pick
their own to suit their mailclient...