Mailing List Archive

Re: Why the new changes need to be "depricated" forever
On Mon, 20 Jul 2020, Richard Troy wrote:

> 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>
>
> [ ... lots deleted, this is just an excerpt ... ]
>
>> 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:

**THIS** is why I called a vote for publicly committing to permanent
backwards compatibility and why I am so painfully dismayed that Kevin
seems to be so set against it.

Kevin, will you *please* reconsider your position, in the interests of the
*USERS*?

Would offering backwards compatibility behind a config option (as Oliver
suggests), and which is never removed absent a compelling technical
reason, be a reasonable compromise?


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If the rock of doom requires a gentle nudge away from Gaia to
prevent a very bad day for Earthlings, NASA won?t be riding to the
rescue. These days, NASA does dodgy weather research and outreach
programs, not stuff in actual space with rockets piloted by
flinty-eyed men called Buzz. -- Daily Bayonet
-----------------------------------------------------------------------
Today: the 51st anniversary of Man's first steps on the Moon
Re: Why the new changes need to be "depricated" forever [ In reply to ]
> **THIS** is why I called a vote for publicly committing to permanent
> backwards compatibility and why I am so painfully dismayed that Kevin
> seems to be so set against it.
>
> Kevin, will you *please* reconsider your position, in the interests of the
> *USERS*?
>
> Would offering backwards compatibility behind a config option (as Oliver
> suggests), and which is never removed absent a compelling technical
> reason, be a reasonable compromise?
>

I am opposed to the use of racially charged language in the software and
would therefore be opposed to permanent backwards compatibility. I am
however supportive of a period of transition and I am working hard trying
to find a good middle ground technically so admins have a straightforward
path for the installation of SpamAssassin 4.0. I am open to discussions
on how to make that happen and have mentioned that on the thread with the
PMC.


Regard,
KAM
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On 21 Jul 2020, at 12:38, Kevin A. McGrail wrote:

> I am opposed to the use of racially charged language in the software
> and
> would therefore be opposed to permanent backwards compatibility.

I believe this is a perfectly fine _personal_ stance for you to
have—and which does not have to be shared by others to be valid. FWIW
I applaud your position and your will to act consistently with what you
think is the right thing to do, even if we disagree on what that is. I
also think the course of a project like this should not be set by a
single individual.

It has been made obviously clear that your views on what constitutes
"racially charged" language are not universally shared, without
venturing into "what to do about it" territory. In addition, yesterday,
you also included this fragment in a FAQ of sorts you circulated:

>> What about rules like URIBL_BLACK?
>
> That is a 3rd party rule. We will discuss with the URIBL team about
> their plans [?]

Based on context, I think it's more than fair to conclude that you
consider even obviously innocent uses of the word "black" as "racially
charged". Will "latin" as in "Latin-1" come next? What about other
colors such as "brown", "red" and "yellow"?

Recognizing that language is a living thing, will devs embark in a
crusade every time a new term becomes "racially charged", devoting hours
to removing them from the codebase? (Yes, I understand that for most,
this is merely a volunteer role but the question is still relevant
because it is guaranteed to impact speed of improvement and quality for
the project.) Will users continue to be forced to play along?

I believe the PMC should review this situation and take appropriate
action. It seems to me at least, that the assertions sustaining the
decision to drop the terms that you consider "racially charged", are not
holding. I am also afraid of the impact this will have in the support
and adoption of SA.

Best regards

-lem
Re: Why the new changes need to be "depricated" forever [ In reply to ]
I find it interesting that Kevin was repeated asked, requested, and demanded by various PMC members to do his changes in a branch, where they would not impact users and other developers. He refused, stating that "his staff" had too much work already invested in changes to trunk, and moving to a branch would void all this work.

On PMC member request for who "his staff" was/were, he refused to answer. It is pretty obvious from the way he is committing changes that there is no "staff", and this is being used as an excuse to force the changes piecemeal into trunk directly, where they will hopefully be hard to back out.

I have never worked on a project where I had patches to trunk on my machine and where I could not split a branch, and then directly apply ALL of the existing patches to that branch, usually with a single command to re-link my local trees to the branch rather than trunk. I can't imagine how, having patches that work against the current SA trunk, someone could not split a branch today, and the patches would not work against that branch. After all, the branch would be identical to trunk, so if the patches applied to trunk, they would apply to the branch.

I am not privy to the PMC voting, other than Kevin's public statement that the vote to make this change "passed by +1". I do not know how many PMC members there are, and I do not know if that information is publicly available. I doubt that voting roles are publicly available. But I do wonder how many of the total PMC members voted on this change. And I wonder how many of the total PMC members would vote in favor of this change if given a second chance to vote at this point in time. Several people have publicly admitted to being PMC members, and also publicly expressed their dismay at how this change is being implemented.

It seems obvious that there is a good reason that Kevin refuses to commit changes to a branch, and to develop the full change before submitting it for merging into trunk. It is very easy to review changes in a branch and determine if they are worthwhile by the time they are fully implemented. After all, that is the point of a branch: to give a place that changes can be developed, and then a reasonable project-group-level decision be made on when, how, and if, to include all or part of the branch changes in trunk. This means it is easy to decide that a change, no matter how much work it was to develop, is really not appropriate in its current form, and it remains still-born in the branch forever. Because there is a single gate where the patch can be committed to trunk or rejected.

By implementing the changes directly, and piecemeal, in trunk, the obvious hope is that they will become interspersed with unrelated changes (as is happening), and, at the completion of an unspecified period for the "complete" implementation, it will be too hard to back out the changes from trunk, no matter how much the desire may be to do so.

I do not know how PMC voting works. I do not know if there is any structural capability for the PMC members to review previous votes and decisions. It may be that there is not, and a vote once made, no matter how disastrous the consequences, cannot be reviewed, amended, or outright disavowed by a new vote. However, hoping that the PMC is some form of governance committee, and consists of more than Kevin, I would hope that there is some chance of reviewing the previous vote.

I would also hope that they have some control over how changes are committed to the SA trunk, and could not request, but direct, that the current changes be moved to a branch, and all further development of these changes be made in that branch. Only when the branch was specified by its authors as complete should a decision, in the form of a vote, be made on when and how to merge the branch into trunk.

Such a vote should be made by the full PMC, and not by a quorum of one member. I think we know how the vote would go if only a single member can carry a vote in a meeting he convenes for the purpose just by himself.

Respectfully,

Loren Wilton

----- Original Message -----
From: Luis E. Muñoz
To: SpamAssassin Developers list
Sent: Tuesday, July 21, 2020 5:14 PM
Subject: Re: Why the new changes need to be "depricated" forever


On 21 Jul 2020, at 12:38, Kevin A. McGrail wrote:

I am opposed to the use of racially charged language in the software and
would therefore be opposed to permanent backwards compatibility.

I believe this is a perfectly fine personal stance for you to have—and which does not have to be shared by others to be valid. FWIW I applaud your position and your will to act consistently with what you think is the right thing to do, even if we disagree on what that is. I also think the course of a project like this should not be set by a single individual.

It has been made obviously clear that your views on what constitutes "racially charged" language are not universally shared, without venturing into "what to do about it" territory. In addition, yesterday, you also included this fragment in a FAQ of sorts you circulated:

What about rules like URIBL_BLACK?

That is a 3rd party rule. We will discuss with the URIBL team about their plans [?]

Based on context, I think it's more than fair to conclude that you consider even obviously innocent uses of the word "black" as "racially charged". Will "latin" as in "Latin-1" come next? What about other colors such as "brown", "red" and "yellow"?

Recognizing that language is a living thing, will devs embark in a crusade every time a new term becomes "racially charged", devoting hours to removing them from the codebase? (Yes, I understand that for most, this is merely a volunteer role but the question is still relevant because it is guaranteed to impact speed of improvement and quality for the project.) Will users continue to be forced to play along?

I believe the PMC should review this situation and take appropriate action. It seems to me at least, that the assertions sustaining the decision to drop the terms that you consider "racially charged", are not holding. I am also afraid of the impact this will have in the support and adoption of SA.

Best regards

-lem
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On 7/21/2020 8:14 PM, Luis E. Muñoz wrote:
>
> Based on context, I think it's more than fair to conclude that you
> consider even obviously innocent uses of the word "black" as "racially
> charged".
>
No, that's simplistic and no one on this project is simple.  We'll
handle issues on a case-by-case basis.  I hope that with
whitelist/blacklist & master/slave, we have identified the racially
charged language in our project.  If you know of any others, please
speak up as it will help the process to be smoother.

> will devs embark in a crusade every time a new term becomes "racially
> charged", devoting hours to removing them from the codebase?

As a foundation that does not pay for code, what a dev devotes their
time to handling is not something we choose. 

Beyond that, those who have earned merit on the project control the
project.  That is the PMC and they have voted on this change.  The ASF
is a meritocracy and those who have no merit do not get a vote.  I have
earned merit and have a vote.  I have exercised it and the change
represents a We not an I.

> I believe the PMC should review this situation and take appropriate
> action. It seems to me at least, that the assertions sustaining the
> decision to drop the terms that you consider "racially charged", are
> not holding.
>
You might be misunderstanding this thread.  We are specifically
discussing a change to extend the period of time where backwards
compatibility is supported.  Right now, that is no less than 1 year and
not until a version change like 4.1 is released.

> I am also afraid of the impact this will have in the support and
> adoption of SA.
>
I'm not afraid of the support or adoption.  There are numerous products
and companies in the ecosystem that will be supporting the change and
they represent a statistically substantial portion of the users.  Don't
let a vocal minority drive change.  To paraphrase Henry Ford, if you
asked people what they want in a car, they'd have said a faster horse.

Regards,

KAM

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On 7/21/2020 9:13 PM, Loren Wilton wrote:
> It seems obvious that there is a good reason that Kevin refuses to
> commit changes to a branch,

I'm not "refusing" to commit to a branch.  Facts:

A) The PMC voted to use trunk, not a branch in February for 4.0.  I have
asked for a 4.0 branch and the vote from February to be reconsidered.

B) Because the changes rely on masscheck/ruleqa which runs only on
trunk.  There are only a few of the developers on the project familiar
with masscheck/ruleqa at this point.  There is no need to insinuate
otherwise and others can see you are well aware of this issue from the
ticket YOU opened: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7837

> By implementing the changes directly, and piecemeal, in trunk, the
> obvious hope is that ....

Don't invent nonsense for the motives behind the code change.  The hope
is by committing the changes needed for whitelist_to, we can establish
the roadmap for all the other options, what effect it has on
masscheck/ruleqa, how it will work in a system where we publish one
ruleset but try and support versions > 10 years old.

Right now, I'm waiting for the next ruleset to be published so we can
make sure it does what we want for 3.3.x to 3.4.x as well as 4.0.0.

Regards,

KAM

--

Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On 21 Jul 2020, at 18:38, Kevin A. McGrail wrote:

> On 7/21/2020 8:14 PM, Luis E. Muñoz wrote:
>>
>> Based on context, I think it's more than fair to conclude that you
>> consider even obviously innocent uses of the word "black" as
>> "racially
>> charged".
>>
> No, that's simplistic and no one on this project is simple.  We'll
> handle issues on a case-by-case basis.

This is at least, troublesome and underscores one of my fears – that
this will repeat over and over as new terms are found to be "racially
charged" by some group.

> I hope that with
> whitelist/blacklist & master/slave, we have identified the racially
> charged language in our project.  If you know of any others, please
> speak up as it will help the process to be smoother.

The words you have listed are arbitrary – in the sense that were
selected by a specific, "case by case" if you will, criteria. In the
questions from my message that you elided, there were a few examples
– various colors and "latin". Those examples are apropos to your
comment on URIBL_BLACK.

There was also mention to the terms "Apache" and "Assassin" in the
earlier threads – if anything, to me the word Assassin is more
concerning than the term blacklist – yet you won't hear me forcing
others to rename their software.

>> will devs embark in a crusade every time a new term becomes "racially
>> charged", devoting hours to removing them from the codebase?
>
> As a foundation that does not pay for code, what a dev devotes their
> time to handling is not something we choose. 

Of course, and I acknowledged that rather openly in my response. Part of
the sentiment on the threads about this topic are related with the way
in which the changes are being implemented and the impact to the users.

> Beyond that, those who have earned merit on the project control the
> project.  That is the PMC and they have voted on this change.

Sure, I accept that. The point I was trying to make is that you are
forcing a change to happen in a way that impacts users
disproportionally. The refusal to make the changes in a branch, and
then, the failure to acknowledge the need for a long-term "compatibility
mode" are IMO short-sighted. The conflating of your personal beliefs and
project goals also speaks volumes about the lack of accountability and
direction at play here.

>   The ASF
> is a meritocracy and those who have no merit do not get a vote.  I
> have
> earned merit and have a vote.  I have exercised it and the change
> represents a We not an I.

Thank you for the explanation – I already inferred the above from the
threads about this issue in which I've participated, just as I've
inferred that the way in which the change is being implemented is
unlikely to closely match the details under which said vote was cast.
Reminds me of Brexit.

>> I am also afraid of the impact this will have in the support and
>> adoption of SA.
>>
> I'm not afraid of the support or adoption.  There are numerous
> products
> and companies in the ecosystem that will be supporting the change and
> they represent a statistically substantial portion of the users. 

I commend you in your ability to see into the future. I lack that
ability, but I think I have a more pragmatic position.

For many users, installing SpamAssassin is simply running a command on
their systems, that they perhaps have written down in a cheat sheet. If
they install and the software fails, I suspect that some of them will
simply uninstall and try the next option. That results in one less user.

For entities or organizations that have invested time and resources
learning the software, this might not be a deal breaker – depending
on the amount of breakage that the implementation of changes will bring.
At some point, they will get tired of addressing these issues and will
either fork or abandon.

None of these scenarios lead to more users. In the absolute best case,
you will have the same user base, all things being equal. And in all
cases, the users will have to change something that has been working
like it is for years and was not broken to begin with.

> Don't let a vocal minority drive change.  To paraphrase Henry Ford,
> if you
> asked people what they want in a car, they'd have said a faster horse.

You choice of source for that quote strikes me as ironic for this
discussion :-)

I do not know where are you getting your data to claim which side of the
argument – and there are more than two – is bigger. But this is
beside the point because evidently this is not a democratic decision,
but a meritocratic one.

Your vote – the vote of the PMC – outweighs that of the users, and
that is clear. I suspect the PMC is forgetting the importance of its
user base, but that is a discussion for another forum. I suppose the PMC
reads this and in choosing to remain anonymous / silent on this matter,
is allowing every participant to form their own opinion on their
motivations.

I guess we'll see what happens.

Best regards

-lem
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On Tue, Jul 21, 2020 at 09:50:22PM -0400, Kevin A. McGrail wrote:
>
> B) Because the changes rely on masscheck/ruleqa which runs only on
> trunk.? There are only a few of the developers on the project familiar
> with masscheck/ruleqa at this point.? There is no need to insinuate
> otherwise and others can see you are well aware of this issue from the
> ticket YOU opened: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7837

Branches are standard way of developing, especially with as extensive
changes as now: https://en.wikipedia.org/wiki/Branching_(version_control)

NOTHING about the proposed changes require testing masscheck/ruleqa
immediately, live and constantly with one by one commits. Masscheck is
pretty much just that, a masscheck script - if one can run it locally
successfully, then it most likely will run successfully in ruleqa. Score
generation isn't much extra over that, even that could be tested locally.
Pretty much everything can be tested locally.

Lacking developers is all more the reason to do extensive local developing
and testing. There is absolutely no reason to rush things for these kinds
of non-technical (political) changes. Using users as guinea pigs for
testing is just sad.
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On Tue, 21 Jul 2020, Kevin A. McGrail wrote:

> Don't let a vocal minority drive change.

Your saying this is painfully ironic to me, because for many of us a vocal
minority *is* what is driving this change.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
There is no better measure of the unthinking contempt of the
environmentalist movement for civilization than their call to
turn off the lights and sit in the dark. -- Sultan Knish
-----------------------------------------------------------------------
104 days until the Presidential Election
Re: Why the new changes need to be "depricated" forever [ In reply to ]
On 7/22/2020 1:45 PM, John Hardin wrote:
> On Tue, 21 Jul 2020, Kevin A. McGrail wrote:
>
>> Don't let a vocal minority drive change.
>
> Your saying this is painfully ironic to me, because for many of us a
> vocal minority *is* what is driving this change.

Actually, no, the original vote was unanimous with +1's but I'm happy to
discuss.  Please continue the discussion on the thread about the
backwards compatibility phasing.

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171