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
