Hi Folks,
I post infrequently - and intend to keep it that way - and want to ensure
my posts have actual value to the community.
First, I'm NOT a member of the dev@spamassassin.apache.org email list and
I surely hope someone who is will kindly forward this email to that list.
List member Oliver Nicole rightly makes the following observations - here
excerpted - about the apparently not just proposed but apparently certain
to happen changes to this project which will negatively impact a great
many people, with a few in-line comments for context before my conclusion.
To wit:
> From: Olivier <Olivier.Nicole@cs.ait.ac.th>
> To: Kevin A. McGrail <kmcgrail@apache.org>
> Cc: users@spamassassin.apache.org, dev@spamassassin.apache.org
> Subject: Re: More Responses about Various Questions revolving around
> WelcomeLIst/BlockList changes
[ ... lots deleted, this is just an excerpt ... ]
> The issue seems to be that you do not understand how real world is
> working. You assume a closed and controled system, which is far from the
> truth.
>
> Every user can build their own rules, they can have scripts that
> generate rules for them, things they put up years ago and they
> completely forget about because it is working fine.
Yes, the above is clearly true. Few of us leave sufficient bread-crumbs to
find our way back to understanding why we did what we did, etc.
> Most likely they will not see the message about the obsolescence, and
> one day, when compatibilty is over, their stuff will stop working and
> there will be no way to solve that ecvept to painfully go back to an
> older version of SA or manually go through all the problems of all the
> angry users.
As a system administrator for some 37 years, and as someone who has acted
in a support or consulting capacity to others in such role(s) for well
over 30 years, I can tell you this observation is quite correct. In fact,
this is the dominant circumstance, by far.
VERY importantly, nobody wants to be stuck on old versions, as Oliver
proposes will happen (and he's right about that), and so this puts system
administrators in a VERY difficult position - a position I'd venture the
proponents don't really understand. The choice is one painful one versus
another painful one. Only someone who's actually been there really gets
it.
> If you offer compatibility with only a warning message, most people will
> ignore (or simply not see) that message and do nothing. And when the
> compatibility is over, they will be facing a wall, just the same as if
> there were no compatibility period. You are just pushing the mayhem back
> by one year.
I'd argue that most won't see it coming at all, though there is, of
course, no way to prove that. But it's simple human nature; when we are
overloaded, as nearly 100% of us perpetually are, we ignore a LOT of
warnings we should have, with our better selves, seen coming, from our
health issues like cancer to our children's issues to computer log files,
it's just what happens; we're simply so busy in our daily lives just
trying to get by that we miss signs we could have seen. The VAST majority
of us are in economic instability, especially with the effects of this
Covid-19 pandemic; to expect us to be paying close attention to warnings
in logs is objectively silly. (Perhaps the proponents of this change are
simply too comfortable in their economics and too isolated from actual
users to see these truths.)
...I believe the above makes the case for why backwards-compatibility
needs to be maintained into perpetuity, but Oliver actually suggests a
neat way to solve this AND the political problem that openly saying that
would create. He writes:
> In fact, I would even suggest that SA 4.0 come with the compatibility
> turned off, so the users are forced to notice the change, with a kind
> and visible message explaining how they can turn the compatibility on
> and that they should upgrade.
Yes, this is, in fact, a BRILLIANT idea because the concept of a
"backwards compatibility" flag in the configuration gives established
users the ability to continue forward without undue pain while at the same
time permitting the linguistically ignorant social justice warriors a
clean victory. "YES, we have vanquished the evil, hurtful words blacklist
and whitelist!" AND, "thank the universe the system still works!" Both
sides can have their way!
AND, of course, the blind-to-what-we-don't-have-to-see populace, such as
the potentially offended by Whitelist and Blacklist, won't see this,
either. So, what they don't know about backwards compatibility will be
completely invisible to them - and even if they see it, they'll think, "OH
GOOD, they got rid of that offensive mess!"
Of course, if there are things that the development team doesn't want to
perpetually support backwards compatibility for, that can easily be worked
out, too, such as resolving those first, and also maybe giving a special
flag for this such as, perhaps, "BackwardsNamingCompatibility" so it
doesn't apply to everything. ... If you WANT to solve this problem, there
is surely a way.
A person dedicated to the engineering change WITHOUT this option is a
person adopting the serious potential end of this project outright, AND
illustrates they really don't give a damn about the project's serving
people. The "one year" plan basically gives a one year lifetime to the
rest of this project, and after that, who knows? Importantly, if they do
this change WITHOUT the backwards compatibility, who knows what OTHER
changes they'll just toss at users without concern for how they adapt?
That is a question I ask as I evaluate which systems to use - as all
others who are wise should also be doing.
To be VERY clear, I AM VERY CIRCUMSPECT ABOUT PROJECTS that do this kind
of thing and generally avoid them. This is a big change. This isn't
something to be taken lightly for the impact on the user community as the
proponents believe it is. And that is the biggest issue here - they
apparently believe this is a no-big-deal you'll-adapt issue, without any
appreciation of the issues. ... How about the proponents give THEIR
backgrounds and state how many years THEY HAVE administering systems and
supporting users, as I and several others here have? As for me, you can
easily use my email address and find out a LOT about me and confirm the
veracity of my remarks. (And, someone else has chimed in with a similar
view as I have with maybe 20 years more experience than I have, I think -
and I hope she contacts me, actually.) ... Honestly, I haven't done the
same with the proponent here of this change, mostly because his lack of
appreciation of the difficulty of this and man-hours spent by the
community clearly illustrates his lack of experience but also because I
really have other things to do and don't really want to be writing to this
list. ... This might be my last post here, IDK - it's certainly been
painful of the time I have available.
IF this project goes forward without said perpetual backwards
compatibility option, I will dump this project ASAP. And now, not later.
Regards,
Richard
--
Chief Scientist somewhere or other you can easily discover.
I post infrequently - and intend to keep it that way - and want to ensure
my posts have actual value to the community.
First, I'm NOT a member of the dev@spamassassin.apache.org email list and
I surely hope someone who is will kindly forward this email to that list.
List member Oliver Nicole rightly makes the following observations - here
excerpted - about the apparently not just proposed but apparently certain
to happen changes to this project which will negatively impact a great
many people, with a few in-line comments for context before my conclusion.
To wit:
> From: Olivier <Olivier.Nicole@cs.ait.ac.th>
> To: Kevin A. McGrail <kmcgrail@apache.org>
> Cc: users@spamassassin.apache.org, dev@spamassassin.apache.org
> Subject: Re: More Responses about Various Questions revolving around
> WelcomeLIst/BlockList changes
[ ... lots deleted, this is just an excerpt ... ]
> The issue seems to be that you do not understand how real world is
> working. You assume a closed and controled system, which is far from the
> truth.
>
> Every user can build their own rules, they can have scripts that
> generate rules for them, things they put up years ago and they
> completely forget about because it is working fine.
Yes, the above is clearly true. Few of us leave sufficient bread-crumbs to
find our way back to understanding why we did what we did, etc.
> Most likely they will not see the message about the obsolescence, and
> one day, when compatibilty is over, their stuff will stop working and
> there will be no way to solve that ecvept to painfully go back to an
> older version of SA or manually go through all the problems of all the
> angry users.
As a system administrator for some 37 years, and as someone who has acted
in a support or consulting capacity to others in such role(s) for well
over 30 years, I can tell you this observation is quite correct. In fact,
this is the dominant circumstance, by far.
VERY importantly, nobody wants to be stuck on old versions, as Oliver
proposes will happen (and he's right about that), and so this puts system
administrators in a VERY difficult position - a position I'd venture the
proponents don't really understand. The choice is one painful one versus
another painful one. Only someone who's actually been there really gets
it.
> If you offer compatibility with only a warning message, most people will
> ignore (or simply not see) that message and do nothing. And when the
> compatibility is over, they will be facing a wall, just the same as if
> there were no compatibility period. You are just pushing the mayhem back
> by one year.
I'd argue that most won't see it coming at all, though there is, of
course, no way to prove that. But it's simple human nature; when we are
overloaded, as nearly 100% of us perpetually are, we ignore a LOT of
warnings we should have, with our better selves, seen coming, from our
health issues like cancer to our children's issues to computer log files,
it's just what happens; we're simply so busy in our daily lives just
trying to get by that we miss signs we could have seen. The VAST majority
of us are in economic instability, especially with the effects of this
Covid-19 pandemic; to expect us to be paying close attention to warnings
in logs is objectively silly. (Perhaps the proponents of this change are
simply too comfortable in their economics and too isolated from actual
users to see these truths.)
...I believe the above makes the case for why backwards-compatibility
needs to be maintained into perpetuity, but Oliver actually suggests a
neat way to solve this AND the political problem that openly saying that
would create. He writes:
> In fact, I would even suggest that SA 4.0 come with the compatibility
> turned off, so the users are forced to notice the change, with a kind
> and visible message explaining how they can turn the compatibility on
> and that they should upgrade.
Yes, this is, in fact, a BRILLIANT idea because the concept of a
"backwards compatibility" flag in the configuration gives established
users the ability to continue forward without undue pain while at the same
time permitting the linguistically ignorant social justice warriors a
clean victory. "YES, we have vanquished the evil, hurtful words blacklist
and whitelist!" AND, "thank the universe the system still works!" Both
sides can have their way!
AND, of course, the blind-to-what-we-don't-have-to-see populace, such as
the potentially offended by Whitelist and Blacklist, won't see this,
either. So, what they don't know about backwards compatibility will be
completely invisible to them - and even if they see it, they'll think, "OH
GOOD, they got rid of that offensive mess!"
Of course, if there are things that the development team doesn't want to
perpetually support backwards compatibility for, that can easily be worked
out, too, such as resolving those first, and also maybe giving a special
flag for this such as, perhaps, "BackwardsNamingCompatibility" so it
doesn't apply to everything. ... If you WANT to solve this problem, there
is surely a way.
A person dedicated to the engineering change WITHOUT this option is a
person adopting the serious potential end of this project outright, AND
illustrates they really don't give a damn about the project's serving
people. The "one year" plan basically gives a one year lifetime to the
rest of this project, and after that, who knows? Importantly, if they do
this change WITHOUT the backwards compatibility, who knows what OTHER
changes they'll just toss at users without concern for how they adapt?
That is a question I ask as I evaluate which systems to use - as all
others who are wise should also be doing.
To be VERY clear, I AM VERY CIRCUMSPECT ABOUT PROJECTS that do this kind
of thing and generally avoid them. This is a big change. This isn't
something to be taken lightly for the impact on the user community as the
proponents believe it is. And that is the biggest issue here - they
apparently believe this is a no-big-deal you'll-adapt issue, without any
appreciation of the issues. ... How about the proponents give THEIR
backgrounds and state how many years THEY HAVE administering systems and
supporting users, as I and several others here have? As for me, you can
easily use my email address and find out a LOT about me and confirm the
veracity of my remarks. (And, someone else has chimed in with a similar
view as I have with maybe 20 years more experience than I have, I think -
and I hope she contacts me, actually.) ... Honestly, I haven't done the
same with the proponent here of this change, mostly because his lack of
appreciation of the difficulty of this and man-hours spent by the
community clearly illustrates his lack of experience but also because I
really have other things to do and don't really want to be writing to this
list. ... This might be my last post here, IDK - it's certainly been
painful of the time I have available.
IF this project goes forward without said perpetual backwards
compatibility option, I will dump this project ASAP. And now, not later.
Regards,
Richard
--
Chief Scientist somewhere or other you can easily discover.
