procmail
[Top] [All Lists]

Re: Who is the procmail maintainer? (revisited 2005)

2005-11-10 05:31:19
Hi there,

On 10 Nov 2005, TjL wrote:
On 06 Nov 2005, Charlie Summers wrote:
On 06 Nov 2005, G.W. Haywood wrote:

FWIW my vote is -1 to making major changes to procmail.

I agree.

if it works for you as-is, use it as is.
...
Why do you insist no one else get new features just because you
won't use them?

Nobody's insisting anything.  Especially, nobody's insisting that
nobody else gets new features.  It's just that we're experienced
enough to know that the phenomenon of 'Galloping Feature Creep' can
cause a great deal of pain to a large number of people.  They might
not make a lot of noise but they nevertheless need to be considered.

No one will force you to upgrade and the source is always there if
you need a 3.5 version.

Ah, it must be wonderful to have such a rosy view of the world.  :)

That's not exactly true, is it?  The distro maintainers will be forced
to use the latest versions in their offerings.  Occasional discoveries
of exploits and vulnerabilities and the resulting security fixes mean
that it's not feasible to use an older distro.  If the much-feared GFC
phenomenon takes hold, it will mean that whenever one installs a new
Linux system he'll be landed with a terrible dilemma: either to use
the latest (untried, flaky, bug-ridden) versions and possibly to have
to make major and time-consuming modifications to a lot of very
personal configurations (which he may have worked on for many years);
or to downgrade a bunch of packages - which, as it's for every new
blessed installation, ultimately will take even longer.  This is not
theoretical.  This happens, and it costs a lot of time.  Have you ever
had a script broken by an upgrade to the latest version of Perl?  Next
you'll want to improve the shell.  Please, leave them alone!

Of course there will be a few bugfixes now and then, and occasionally
this will break a script or two which arguably were themselves broken,
but major new developments need to be 'opt-in' not 'find-a-way-out'.
I have absolutely no objection to anyone having some more features if
they want them, I just don't want development to screw things up for
everyone else in the process.  Or as Bert Lance so eloquently put it:

If it ain't broke, don't fix it.

Is there anything unacceptable about branching a new utility called
'procmail2' or something like that?  It seems to me this could offer
something from both worlds, if not necessarily the best of them.  If
it turned out that it was overwhelmingly more effective than the old
version people would migrate to it, and eventually the older utility
would die a natural death.  Nobody would be seriously inconvenienced
in the process.  The distro maintainers could package both, something
as small as procmail wouldn't make much difference to a 650MByte ISO
if there were two alternatives - after all  have at least six window
managers kicking around on this Slackware box.

73,
Ged.

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail