Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Luis E. Muñoz
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

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Kevin A. McGrail
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

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Kevin A. McGrail
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

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Loren Wilton
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

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Luis E. Muñoz
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 share

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread Kevin A. McGrail
> **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 comp

[Bug 7842] Perl 'indirect object notation' is deprecated, changing to the recommended syntax

2020-07-21 Thread bugzilla-daemon
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7842 --- Comment #1 from Mark Martinec --- trunk: $ svn ci -m "Bug 7842: Perl 'indirect object notation' is deprecated, changing to the recommended syntax" Sendinglib/Mail/SpamAssassin/Bayes.pm Sendinglib/Mail/SpamAssassin/Locker

[Bug 7842] New: Perl 'indirect object notation' is deprecated, changing to the recommended syntax

2020-07-21 Thread bugzilla-daemon
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7842 Bug ID: 7842 Summary: Perl 'indirect object notation' is deprecated, changing to the recommended syntax Product: Spamassassin Version: SVN Trunk (Latest Devel Version)

Re: Why the new changes need to be "depricated" forever

2020-07-21 Thread John Hardin
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 co

Rule updates are too old - 2020-07-21 3.3.0:2020-07-19 3.3.1:2020-07-19 3.3.2:2020-07-19

2020-07-21 Thread darxus
SpamAssassin version 3.3.0 has not had a rule update since 2020-07-19. SpamAssassin version 3.3.1 has not had a rule update since 2020-07-19. SpamAssassin version 3.3.2 has not had a rule update since 2020-07-19. 20200720: Spam and ham are above threshold of 150,000: http://ruleqa.spamassassin.