Re: [ANNOUNCE] Apache SpamAssassin 4.0.1 available
CNAME record to make sa-update work with new version number 4.0.2 that is in svn trunk has been added. sa-update for trunk should now work again. I have updated the checklist for release managers to have the update of the CNAME record be requested at the start of the 72 hour vote period for a full release so that sa-update will continue to work when the version number gets bumped up after the vote passes. Benny, re-reading your email, I see that is not the issue you are bringing up... The downloads directory includes the rules files snapshot as they were at the time of the release build, which can be used by people who don't want to or can't run sa-update after installation. Of course, people should be running sa-update or doing something equivalent to keep their rules up to date. The snapshot rules file is there for anyone who needs it at the time of installation if running sa-update then is not feasible. Sidney Benny Pedersen wrote on 30/03/24 7:08 am: Sidney Markowitz skrev den 2024-03-29 15:25: 7e6093c8514e1b18f3b47215dc97d51b7b70142ca2fe7242362c021bf770b2c1c1e99a8227d1c5b9b5d303e405ab9e6a7c67a60b5b03dcb6588bd68c733e2448 Mail-SpamAssassin-rules-4.0.1.r1916528.tgz replaced fine with sa-update no ? is admins just using this one time and not ever croned update and after upgrade major versions never issue a sa-update :( now that gentoo have binhost, i see more problems to other distro that release precompiled problems anyway thanks for release finaly now
[ANNOUNCE] Apache SpamAssassin 4.0.1 available
9814 gpg --verify Mail-SpamAssassin-4.0.0.tar.bz2.asc gpg --fingerprint FDE52F40F7D39814 Then confirm that the key description shown by --verify matches what is shown by --fingerprint. See https://www.apache.org/info/verification.html for more information on verifying Apache releases About Apache SpamAssassin - Apache SpamAssassin is a mature, widely-deployed open source project that provides filtering to classify email to block spam, malware, and phishes. Apache SpamAssassin uses a variety of mechanisms including mail header and text analysis, Bayesian filtering, DNS blocklists, collaborative filtering databases, and meta concepts to lower incorrect classification. Apache SpamAssassin uses a highly modular architecture that allows other technologies to be quickly incorporated as plugins to easily add or replace existing methods. Apache SpamAssassin typically runs on a server using either command line utilities or an API to classify email so a mail system can use the results before the message reaches mailboxes. Most of the Apache SpamAssassin is written in Perl natively supporting Unix, Linux, and macOS platforms and Microsoft Windows using Strawberry Perl. For more information, visit https://spamassassin.apache.org/ About The Apache Software Foundation Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 100 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 2,500+ contributors. For more information, visit https://www.apache.org/ -- Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
[RESULT] [VOTE] Release of 4.0.1
With four +1, no 0, and no -1 binding votes, the vote to release Apache SpamAssassin 4.0.1 has PASSED. I will now commence the remainder of the release process. Thank you everyone who has helped with coding, testing, and bug reporting for the 4.0.1 release. Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
[VOTE] Release of 4.0.1 - vote will close on Friday, March 29, 2024 06:30am UTC
[This email is bcc'd to the Apache PMC to ensure they notice it] Hello everyone, Calling for a vote on the release of Apache SpamAssassin 4.0.1 Only votes from members of the PMC will be binding, but everyone is encouraged to thoroughly test that these files properly install and pass the make test checks on your platform and any other tests that you can perform. Here are the files that will be released as Apache SpamAssassin 4.0.1 if there are at least three binding +1 votes and more +1 votes than -1 binding votes at the end of the 72 hour voting period, Friday, March 29, 2024 06:30am UTC. Note that the policy on voting for releases is not the same as for voting for code committing where a single binding -1 is a veto. Files are in https://dist.apache.org/repos/dist/dev/spamassassin/ There have been a few minor commits since the release of 4.0.1-rc1. We think those changes are safe, but definitely test these release files to be sure. As per https://www.apache.org/legal/release-policy.html#release-approval please download and check the files on your platform(s) before voting +1 if you approve the release, or -1 and state a technical reason why these files are not ready for release. The current draft of the release announcement can be seen at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.1.txt I vote +1 for release after checking on Ubuntu 22.04, macOS 13, and Windows 10. sha256sum of archive files: 9775ed7559e83ec3e6c03edb2be8ffc7f15cc405fb13e85c148eb0bf191721a8 Mail-SpamAssassin-4.0.1.tar.bz2 5c6bb222e18405f1a276816d04e1ffc5cc90785e1265714b4506c2b541d6d5e5 Mail-SpamAssassin-4.0.1.tar.gz 728ffbc536fcb4f9bb07adfc72eeb706f8ff1257833bf0bf6c70ab2eea01de97 Mail-SpamAssassin-4.0.1.zip 381eadfc7e513e5f735389b78173de5af471f3d06fe6ab8f129634a6644b4bf4 Mail-SpamAssassin-rules-4.0.1.r1916528.tgz sha512sum of archive files: 66183e356b07d1049cf5598fc1e563e4aab580dfca04bf8ec37781dfb57ef568d33c6f6455076f54f940947f5a5dfefa7a08d233833deea5fe5ea18b669cd790 Mail-SpamAssassin-4.0.1.tar.bz2 7ac2d789d8744dfe37f647013871e293de50cfcd792029956eb6cea8e51343aad135398bd91867c3c21a68e5fb6330bd6b38a04b794a24449a59287b46d4ac70 Mail-SpamAssassin-4.0.1.tar.gz efed5a7ae2fb4f200c9f248d61bdda44a6e4103b4245b086c3b94f1880e5cee1f19a7b4d810d4553cc566208970052d4f26cc5512fa4a0e1d0d09d4fa54bdd15 Mail-SpamAssassin-4.0.1.zip 7e6093c8514e1b18f3b47215dc97d51b7b70142ca2fe7242362c021bf770b2c1c1e99a8227d1c5b9b5d303e405ab9e6a7c67a60b5b03dcb6588bd68c733e2448 Mail-SpamAssassin-rules-4.0.1.r1916528.tgz Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org sid...@sidney.com
Re: New Release Candidate: 4.0.1-rc1 - Testers Needed
As several people have reported back to me that they have been running from trunk for a while and they see no problems with this build, I'm going to give this a week from the upload of rc1 (about 25 March) to move to full release, if nobody comes up with any problems for this release candidate. Please try it out before then if you can. At that point I'll create the release build and there will be a 72 voting period before the public release process begins. Sidney Markowitz wrote on 18/03/24 9:23 am: Hello Everyone, 4.0.1 release candidate 1 of Apache SpamAssassin is now available at https://dist.apache.org/repos/dist/dev/spamassassin/ This is a release candidate for the patch release 4.0.1 Please test and post success or failure as soon as possible!
New Release Candidate: 4.0.1-rc1 - Testers Needed
Hello Everyone, 4.0.1 release candidate 1 of Apache SpamAssassin is now available at https://dist.apache.org/repos/dist/dev/spamassassin/ This is a release candidate for the patch release 4.0.1 Please test and post success or failure as soon as possible! If these files don't show any problems I'll call for a vote on moving to full release as the next step. The draft release announcement can be found at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.1.txt Please review it and suggest changes or additions. Also take a look at the UPGRADE file in case anything should be added to it. sha256sum of archive files: cea17193e882c6e15f69f37fa919218e62868f6b941f702a329e372cfbd1e5f5 Mail-SpamAssassin-4.0.1-rc1.tar.bz2 363b45d3c9d41dfa931f6a52ba738f0680fb32b6b9b6235fe6131dc137d20f9e Mail-SpamAssassin-4.0.1-rc1.tar.gz 50ec854b6c29bdc73c428e631ac51919d2812f91cf96aa899a47638b30ed96be Mail-SpamAssassin-4.0.1-rc1.zip 4a2bd546e405612c70464c828c9e3f1ff280c51d89f6c1ba558f9f07cdb0c2da Mail-SpamAssassin-rules-4.0.1-rc1.r1916292.tgz sha512sum of archive files: 8dd58c71423814eb9e3083dde61024b9446d21809e4f35e455d42498976ea4d7bf97425fe8f3ee085dc687c3bc2fffa01a03ae187e4e00e91972972a51789dd3 Mail-SpamAssassin-4.0.1-rc1.tar.bz2 f3c408382a3473c86bb63f32fd30becd7060eac6e4b8b1ac14a213222d74688eb27af74bc70645cf0b6dafb87a2b27b59bc83b85608f4110b953583cb0f684ce Mail-SpamAssassin-4.0.1-rc1.tar.gz 33488e9aa6dfbed22950ce7e2257370c5e3e603a153eed9bda45d86782f7c3b8bbeebf86349ba678a5b4af7729b7ea7cb0bd457d8b2a3fd0236d8b053d5b7e1c Mail-SpamAssassin-4.0.1-rc1.zip 80d62ac8aaacf77198c6c509b515892aed3d9bcea467a92ee9f5dbfeb81a560e2eadc1a9fc6ecef2e099394bdbf0dd7f7ef3932639feb2b2855499b1fb586514 Mail-SpamAssassin-rules-4.0.1-rc1.r1916292.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
New Pre-Release: 4.0.1-pre1 - Testers Needed
Hello Everyone, 4.0.1 pre-release 1 of Apache SpamAssassin is now available at https://dist.apache.org/repos/dist/dev/spamassassin/ This is the pre-release for the patch release 4.0.1 Please test and post success or failure as soon as possible! While I'm not calling this a "release candidate" because it is the first build I'm making available for wider testing, this is just a relatively small patch release and if we are lucky it is all ready to be released. If these files don't show any problems I'll call for a vote on moving to full release as the next step. The draft release announcement can be found at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.1.txt Please review it and suggest changes or additions. Also take a look at the UPGRADE file in case anything should be added to it. sha256sum of archive files: 496538ad779bb4f34603be16377c18f4269fdfa751e10397c182e99c57b8c011 Mail-SpamAssassin-4.0.1-pre1.tar.bz2 9e01ee2d2ca9bf5eb6c58e35c3046813f8c74801aa2e0b13f0db98a1b33cf2d3 Mail-SpamAssassin-4.0.1-pre1.tar.gz 95c14a92c796ad94a44d0b35e1333e8e5d54e67f3c1b7eb8da1ba47de504d18c Mail-SpamAssassin-4.0.1-pre1.zip 6aeb3f00a5b52bab1e394c67134f5a75cd2a807511a3a019b33d39f16cece615 Mail-SpamAssassin-rules-4.0.1-pre1.r1914002.tgz sha512sum of archive files: ba25997241d8a25ddad025669e9186038e628412eefea99c1ba09b1a908814a92e280c4c18e5fc1c565f57bfd47b2f979116489ca0cf450be070b4a56d321e51 Mail-SpamAssassin-4.0.1-pre1.tar.bz2 e58595382a75906ddfc90f50eb301079691c63a70aebe3d878ba142093618d8f1bdfe02fb395be00dc4350bdef130cfa2b7f689dcd8e8f4e68bee2ed1b5cc635 Mail-SpamAssassin-4.0.1-pre1.tar.gz 5f1df5476ebf71caa67a31a7fde6a685e152a87619f41f1f5f83c8520e08fb7426d84f9c6b3d2a7dccd771e0bb804f3c8ddf7a19d6c2c49e26b0130924be4b08 Mail-SpamAssassin-4.0.1-pre1.zip 1fe1c4c5cc2d0e1f68ac542667524b2d24c9526c2a531e4adfbc328b254f83c13a248ff1a9b8eb5d906343c92f9ad317eb6fef4ecb6ffca0ffd69ea21ec9dd7d Mail-SpamAssassin-rules-4.0.1-pre1.r1914002.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: Unsupported locale may crash interpreter warning
If it is just a test and you know where to remove it, please go ahead. giova...@paclan.it wrote on 23/11/23 4:43 am: On 11/22/23 12:34, Sidney Markowitz wrote: Does this look like something that needs to be worried about? I got the impression from some googling that the warning was introduced in perl 5.38, but the behavior being warned about always existed. cp936 encoding has never being supported by Perl, in Perl 5.38 they added the warning (see also https://github.com/Perl/perl5/issues/21562#issuecomment-1763252665). I think we should not test using those encodings. Giovanni Running make test from trunk t/basic_lint.t 5/11 Locale 'zh_CN.GB2312' is unsupported, and may crash the interpreter. t/basic_lint.t 6/11 Locale 'zh_CN.GBK' is unsupported, and may crash the interpreter. t/basic_lint.t 7/11 Locale 'zh_CN.GB18030' is unsupported, and may crash the interpreter. -- sidney
Unsupported locale may crash interpreter warning
Does this look like something that needs to be worried about? I got the impression from some googling that the warning was introduced in perl 5.38, but the behavior being warned about always existed. Running make test from trunk t/basic_lint.t 5/11 Locale 'zh_CN.GB2312' is unsupported, and may crash the interpreter. t/basic_lint.t 6/11 Locale 'zh_CN.GBK' is unsupported, and may crash the interpreter. t/basic_lint.t 7/11 Locale 'zh_CN.GB18030' is unsupported, and may crash the interpreter. -- sidney
Re: New dependency on Devel::Cycle???
The only place I see it is in t/memory_cycles.t which checks for
use constant HAVE_DEVEL_CYCLE => eval { require Devel::Cycle; };
plan skip_all => "Devel::Cycle module required for this test" unless
HAVE_DEVEL_CYCLE;
But it is listed as a test dependency without qualification in
Makefile.PL. That's not right, probably my mistake. I'll correct it.
Sidney
Bill Cole wrote on 21/11/23 3:04 am:
Just tried a build on trunk, got this:
NOTE: settings for "make test" are now controlled using "t/config.dist".
See that file if you wish to customize what tests are run, and how.
checking module dependencies and their versions...
checking binary dependencies and their versions...
dependency check complete...
Warning: prerequisite Devel::Cycle 0 not found.
Looks like it is needed for a new test?
Not sure how to make that optional for tests only but we need to do
something, even if it is just documentation.
Preparing a 4.0.1 release
It's been proposed on the PMC mailing list that we put out a new 4.0.1 release to incorporate bug fixes since 4.0.0 Since that is a public dev matter, and there were no objections raised, I'm moving further discussion here to the pubic dev mailing list. I'm volunteering to manage the release. First step will be to go through open bugs that are targeted for 4.0.1 to determine if they can be closed or targeted for a future release. If there are any open bugs that do not already have a 4.0.1 target that you think really should be fixed for this release, or even better that you can fix in a quick, simple, and safe enough manner to justify getting in to this release, please speak up. Regards, Sidney
Re: Spam from Google bypass filters due to USER_IN_DEF_DKIM_WL
Giovanni Bechis wrote on 28/12/22 11:43 pm: Hi, recently I started receiving more spam from "drive-shares-noreply at google.com", this spam bypasses filters because it matches USER_IN_DEF_DKIM_WL that gives the email -7.5 points. Should we remove google.com from default whitelists ? Spample at: https://pastebin.com/hVD3FCCe Giovanni I just generated one of those as a test by going to Google Slides, creating a slide presentation, then File | Email and sent the presentation to arbitrary email addresses with a message I typed in. The email arrives from drive-shares-noreply just like your sample, with my Google account's email address as the Reply-To. As Henrik pointed out, there are legitimate Google addresses in USER_IN_DEF_DKIM_WL, but email from drive-shares-noreply at google.com can be generated by anybody from throwaway accounts and should not be automatically welcome listed.
Re: Question about branching svn
Henrik K wrote on 19/12/22 5:43 am: Mass check runs from trunk, there are no ties to any specific version, aside from testing built rules.tar.gz with all 3.4 and 4.0 releases. It seems like 1. Branching svn would not impact mass check, which will continue to run from trunk 2. If we ever decide to move to git, we could if we wanted to stage the process by keeping the rules and rulesrc directories in svn at first with minimal change to build and mass-check scripts 3. We don't have a compelling reason to have to move to git, nor do we have committers clamoring to move to git, nor do we have a total consensus to move to git. We do have some committers who would like a move to git. That leaves it in the realm of something to keep in mind but not to go through the effort of implementing right now. 4. We don't need to branch until someone presents something big enough to justify having separate 4.0.x and 4.1.x development branches. More specifically, we would have to have something that we commit to trunk that is not ready for an immediate release, and we would have to have a reason to release a 4.0.x immediately without that partial code that was committed to trunk. As Henrik pointed out, we can adopt some of the git development philosophy of using a feature branch to develop a feature and only committing to trunk when it is finished. It isn't the "svn way" but it would work and would avoid problems like we had with large changes like welcome/blocklist renaming. 5. We don't currently have any big plans for changes in SpamAssassin 4.1 now that the move to Unicode support is finally completed. If it turns out that the future of SpamAssassin is in ongoing work om rules, the masscheck process, and new plugins, I can see that there may never be a reason to create separate major/minor version development branches. 6. That said, I'm certainly open to hear from anyone who does have any proposal for future features and improvements. Regards, Sidney
Re: Question about branching svn
Henrik K wrote on 18/12/22 8:18 pm: This is atleast third discussion of the same? All the previous times it was concluded that branching wasn't necessary. Backporting is a pain and usually something is forgotten. It's not like we have any real developing going on, does anyone even have a guess what a new big 4.1 feature would be? I've been through the discussion about a million more times than that, essentially every time I've had a release on some project that used svn. The only thing that changes is the opinions of the developers at the time, and maybe what new work they already know is pending. However, since those are different each time it is worth asking the question. I don't want to create a tedious discussion, just find out if there is a consensus and if there are any strong reasons for branching or for not branching right now. Henrik, you do bring up something that I think is pretty relevant for the question of branching: Is there anything planned yet that we know would be for 4.1.0 and would not be for 4.0.1? Does anyone have anything in mind yet for future SpamAssassin, or have we all been too focused on the 4.0.0 marathon? For any major changes that threaten stability (like our wl/bl or meta change), a temporary branch could be used for publishing things for others to test, especially if not committed to work on it actively. Pushing normal fixes or new plugins to trunk would fine. Just please, do atleast a make test before committing. And this is what I like about working with git instead of svn. It took me a bit to get used to it, but it is so much easier to use git branches in that way. I never had to go through the team discussion on a project that used git about whether to branch or the right time to branch for developing a point release vs a major version branch, or have difficulty backporting the way it always happens with svn. If migrating to git is "the Apache way" I don't feel any pressure from anyone, inside or outside the PMC to switch from svn. Infra seems happy to keep running the svn servers for as long as we want to keep using them. I do want to get a sense for how many of prefer git, how many are comfortable using git and wouldn't mind if we did switch, how many are not experienced with it or have never worked with it. Sidney
Re: Question about branching svn
Kevin A. McGrail wrote on 18/12/22 3:45 pm: One con is that we do need to get masscheck and various tools on the server to work with the new 4.0 release. I'm not sure my eyesight is good enough to do it anymore but I'm happy to help! Questions: If I were to go ahead and branch, would that break masscheck and/or any other tools that are in use? If so, how do we coordinate doing the branching with whatever has to be changed in those scripts and processes? Who besides you has the knowledge to make those changes? I've been assuming that it is everyone I see doing masscheck and rule update and ruleqa/sysdmin list stuff that I haven't involved myself with, but is there actually more of a bottleneck going on?
Re: Question about branching svn
Sidney Markowitz wrote on 18/12/22 9:42 am: > Now that we have released 4.0.0, we can if we want create a 4.0 branch > and have trunk be for a 4.1 branch. Or an alternative that just came to mind: Is this perhaps the time for us to switch from svn to git? We already have the git mirror of svn that Infra set up. We would have to deal with all scripts that interact with the svn repo. Maybe finally split rules into a separate git repo. So it would be some work. But now that 4.0.0 is out perhaps it is the best time to do that work? Sidney
Question about branching svn
Now that we have released 4.0.0, we can if we want create a 4.0 branch and have trunk be for a 4.1 branch. Pros: If we do it now, then if something comes up that is important enough to require a 4.0.1 patch release, we will not have commits already in svn that are not suitable for being 4.0.1, either because they are not yet finished, or not tested, or too extensive. We can only commit to the 4.0 branch things that are completed and tested and deemed safe enough that 4.0 branch will always be stable and available for a 4.0.1 release if the need arises. Branching now means we don't have to worry that what we commit to trunk may end up unsuitable for a future 4.0 branch. Cons: Until someone actually works on something that we would want in 4.1.0 and not in a hypothetical 4.0.1, we have to consider every commit to trunk and replicate it in the 4.0 branch. We could instead put off branching until there is something to commit to trunk that we might not want in 4.0.1 or that would have to be reverted as part of the process of creating a branch. Thoughts on this? Branch now or branch later? Sidney
[ANNOUNCE] Apache SpamAssassin 4.0.0 available
p.org --recv-key FDE52F40F7D39814 gpg --verify Mail-SpamAssassin-4.0.0.tar.bz2.asc gpg --fingerprint FDE52F40F7D39814 Then confirm that the key description shown by --verify matches what is shown by --fingerprint. See https://www.apache.org/info/verification.html for more information on verifying Apache releases About Apache SpamAssassin - Apache SpamAssassin is a mature, widely-deployed open source project that provides filtering to classify email to block spam, malware, and phishes. Apache SpamAssassin uses a variety of mechanisms including mail header and text analysis, Bayesian filtering, DNS blocklists, collaborative filtering databases, and meta concepts to lower incorrect classification. Apache SpamAssassin uses a highly modular architecture that allows other technologies to be quickly incorporated as plugins to easily add or replace existing methods. Apache SpamAssassin typically runs on a server using either command line utilities or an API to classify email so a mail system can use the results before the message reaches mailboxes. Most of the Apache SpamAssassin is written in Perl natively supporting Unix, Linux, and macOS platforms and Microsoft Windows using Strawberry Perl. For more information, visit https://spamassassin.apache.org/ About The Apache Software Foundation Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 100 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 2,500+ contributors. For more information, visit https://www.apache.org/ -- Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
[RESULT] [VOTE] Release of 4.0.0 - vote will close on Saturday, December 17, 2022 09:00am UTC
With five +1, no 0, and no -1 binding votes, the vote to release Apache SpamAssassin 4.0.0 has PASSED. I will now commence the remainder of the release process. Thank you everyone who has helped with coding, testing, and bug reporting in the almost eight years since we split off the 3.4 branch in svn to start parallel work towards a 4.0 release. Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: [VOTE] Release of 4.0.0 - vote will close on Saturday, December 17, 2022 09:00am UTC
Michael Peddemors wrote on 15/12/22 6:28 am: It is a time for rest and relaxation, so you MAY want to delay 4.0 release until after the holidays ;) This way everyone can install the new version while all the mail servers are shut down for their annual solstice to New Year break :)
Re: Draft report to the Board for Dec 2022
My apologies for fat-fingering an email that was supposed to be sent to the private PMC mailing list. At least it didn't contain anything confidential. The link in there will not be publicly readable until after the Board meeting happens on 21 Dec, and now you all have a tiny glimpse of the exciting procedures the PMC engages in on our private mailing list, but I'm glad this slip was not too bad. Regards, Sidney
Draft report to the Board for Dec 2022
Hi everyone, I don't see the usual reminder for our quarterly report to the Board, but the usual schedule calls for it being due on the second Wednesday of the month (time zone never specified, and whether at the beginning or by the end of the Wednesday never specified either). I've put together a draft on the wiki that mentions that were are holding a vote for a release of 4.0.0 on December 17. https://cwiki.apache.org/confluence/x/HpQODg The draft report is on the wiki with PMC having edit access. I'll go ahead and send it in some hours from now. If you have anything to add that the Board will probably be interested in, feel free to edit it. Regards, Sidney
[VOTE] Release of 4.0.0 - vote will close on Saturday, December 17, 2022 09:00am UTC
[This email is bcc'd to the Apache PMC to ensure they notice it] Hello everyone, Calling for a vote on the release of Apache SpamAssassin 4.0.0 I noticed that the official guidelines on the release process https://www.apache.org/legal/release-policy.html#policy say that they encourage the votes include the dev community. It also says that making the release files available to readers of the developer mailing list does not violate the rules against publishing them prior to the release vote. Only votes from members of the PMC will be binding, but everyone is encouraged to thoroughly test that these files properly install and pass the make test checks on your platform and any other tests that you can perform. Here are the files that will be released as Apache SpamAssassin 4.0.0 if there are at least three binding +1 votes and more +1 votes than -1 binding votes at the end of the 72 hour voting period, Saturday, December 17, 2022 09:00am UTC. Note that the policy on voting for releases is not the same as for voting for code committing where a single binding -1 is a veto. Files are in https://people.apache.org/~sidney/devel/ The only code change since the release of 4.0.0-rc4 has been the commit in Bug 8087 https://svn.apache.org/viewvc?view=rev=1905867 As per https://www.apache.org/legal/release-policy.html#release-approval please download and check the files on your platform(s) before voting +1 if you approve the release, or -1 and state a technical reason why these files are not ready for release. The current draft of the release announcement can be seen at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt I vote +1 for the release after checking on Ubuntu 22.04, macOS 13, macOS 12, and Windows 10. sha256sum of archive files: e5aa17050a30bc72baa86afdc6048cadea4d1ec2ecc61d787717a059b8319e88 Mail-SpamAssassin-4.0.0.tar.bz2 65979da7d103e3c37563f23a1a24f470090afb33664348968a00bf3d09a84f36 Mail-SpamAssassin-4.0.0.tar.gz 063d59ab2c7a67c1707b5b6a6063f97bdc9e3e8ae1246f1d43aa3dd32bf35d06 Mail-SpamAssassin-4.0.0.zip ae4ffbb917ebc7fefa7240fc5bb5151dda663f8e4059161ad7c9b42eed1bac6d Mail-SpamAssassin-rules-4.0.0.r1905950.tgz sha512sum of archive files: a0fe5f6953c9df355bfa011e8a617101687eb156831a057504656921fe76c2a4eb37b5383861aac579e66a20c4454068e81a39826a35eb0266148771567bad5f Mail-SpamAssassin-4.0.0.tar.bz2 db8e5d0249d9fabfa89bc4c7309a7eafd103ae07617ed9bd32e6b35473c5efc05b1a913b4a3d4bb0ff19093400e3510ae602bf9e96290c63e7946a1d0df6de47 Mail-SpamAssassin-4.0.0.tar.gz d907d59fd6af1560b0817d5397affeb096feaffd01614481b22a172976798f0ab438a7fb4d6878dfbb8338961f888dd69c2f7d9e743a48164e2842fa6f804571 Mail-SpamAssassin-4.0.0.zip 8ff0e68e18dc52a88fec83239bb9dc3a1d34f2dcb4c03cd6c566b97fa91242e3c8d006612aeb4df0acf43929eaaa59d542eb5cf904498343adf5eadefcb89255 Mail-SpamAssassin-rules-4.0.0.r1905950.tgz Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org sid...@sidney.com
Are we ready for the actual 4.0.0 release?
The only non-test code commits since rc4 were the tiny DMARC fix for bug 8087. Nothing else important has been reported since the rc4 release. Is this it? Are we ready? If nobody posts any last minute reasons to hold off on releasing what we have now, I'll start the process of building and releasing 4.0.0. Finally! Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
New Release Candidate 4.0.0-rc4 Testers Needed
Hello Everyone, 4.0.0 release candidate 4 is now available at https://people.apache.org/~sidney/devel It can also be installed from CPAN using tools such as cpanm, e.g. cpanm SIDNEY/Mail-SpamAssassin-4.0.0-rc4-TRIAL.tar.gz Very little has changed from the rc3 release, mostly fixes to tests rather than code, and some work to make meta rule processing work more sensibly. I am very hopeful that after a quick look at rc4 we will be ok for a full 4.0.0 release. Please test and post success or failures as soon as possible. The current draft of the release announcement/notes that has been prepared for the 4.0.0 release can be viewed at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt That file also contains the instructions for how to verify the hashes and GPG signatures of the downloaded files. The extensive document on upgrading from 3.4.x and new features is at https://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE sha256sum of archive files: 4155a388ba42027984f33e29cdf68d256d80156eada7b2d3ad23138984735114 Mail-SpamAssassin-4.0.0-rc4.tar.bz2 ed6bbd42a2ec3279306b8395c9a573eedcda7eae40f2cf12bd2e59c9cb22b41f Mail-SpamAssassin-4.0.0-rc4.tar.gz 90c467f026d43885c277ee5ba005bff4eb6439b712aeff5e0ae7c776529bcd17 Mail-SpamAssassin-4.0.0-rc4.zip 0f36112996eeff8e32eca03828c204e4f2bc4df77b8fa6eeb830d373c4a29524 Mail-SpamAssassin-rules-4.0.0-rc4.r1905746.tgz sha512sum of archive files: 5e453ad3e85bf7057db8baf171ca097cca5b1f4b18066d0b8bb93d5ec1c87d2280fef358224d9adc13b4bd99f70661b27bd270dd2163a5b4de04fd3e8a4d351a Mail-SpamAssassin-4.0.0-rc4.tar.bz2 41235b1e50d129b7f58392d730f693077c20d9ea8e83ad5da51572b3433961382e6c5f2aaad0f5a4320f1b65e11e97ebe9f8f701d94109b03ff1fdf16bcaacc7 Mail-SpamAssassin-4.0.0-rc4.tar.gz 0ecc2cdb84f9ef4ba7014941f0315629c289e510fa676ecbe2cfc166c561b1a26caab98b33898ae19fb02067f5eccd53e6e0e407ecf1ab7ff6d57071826d53c5 Mail-SpamAssassin-4.0.0-rc4.zip 38afed9782f83fbb61425cac7016cbc177048f1305703bcac889d1ec75b7eea012750ab689c57c30cf8a8494c8f93a621cccd32d02157c6d57416284e8be2715 Mail-SpamAssassin-rules-4.0.0-rc4.r1905746.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
In RTC mode for RC4 and hopefully for release
The remaining issues targeted for 4.0.0 have been closed. I'm declaring us in R-T-C mode now while I get an RC4 building. If it looks good, we can go right on to the 4.0.0 release. I'm not calling for a formal vote on R-T-C. Any committer can vote -1 to veto the R-T-C announcement if you present a reason, so we can be informal about it. Please don't commit anything except tests, rules, comments, and documentation without an associated Bugzilla issue and review votes. I have been working on Github Action scripts that facilitate running all the regression tests in multiple versions of perl on Github Action virtual machines. Because of resource availability we can't run those on our ASF Github account, but it should allow anyone to fork the Github mirror of our svn repo to their personal Github account and run a complete suite of regression tests that way on Ubuntu Linux, Windows, and macOS. I haven't committed that stuff to trunk yet, but as all of it is in test files or in a directory used only for Github actions, it will not be subject to R-T-C rules. I'll only finish it before building RC4 if it doesn't hold me up past today. Regards, Sidney
Next steps for RC4
The remaining open bugs targeted for 4.0.0 are 8077 and 8078. 8077 has the votes, ready for Giovanni to commit and close the issue. 8078 is a blocker for 4.0.0 and is pending Henrik getting time to spend on investigation. So that is more open-ended. I am ready to build an RC4 as soon as the open issues are cleared, and I would like to move very quickly from RC4 to full release with minimal further testing other than the full build and regression testing. To that end I propose that we only target any new issues for 4.0.0 if they can be closed very safely and quickly, and if there is reason not to put them off to a future 4.0.1 release. The goal will be to really be finished with 4.0.0 after 8078 is finally done. Of course, that's a goal. We should not ignore anything truly serious that shows up at the last minute. Regards, Sidney
New Release Candidate 4.0.0-rc3 Testers Needed
Hello Everyone, 4.0.0 release candidate 3 is now available at https://people.apache.org/~sidney/devel It can also be installed from CPAN using tools such as cpanm, e.g. cpanm SIDNEY/Mail-SpamAssassin-4.0.0-rc3-TRIAL.tar.gz This rc fixes all previously open issues targeted for 4.0.0. The issues found and fixed in rc2 were few and minor. We continue to progress towards a full release. Please test and post success or failures as soon as possible. The current draft of the release announcement/notes that has been prepared for the 4.0.0 release can be viewed at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt That file also contains the instructions for how to verify the hashes and GPG signatures of the downloaded files. The extensive document on upgrading from 3.4.x and new features is at https://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE sha256sum of archive files: 00d49ddadf5f42db858f973e01e948bef9b016870de6928fb217b501e564a4c5 Mail-SpamAssassin-4.0.0-rc3.tar.bz2 ad3b26ddcf5d253dc10d7cbefece5c8686589f7f58fb6a9534b823ecae51140a Mail-SpamAssassin-4.0.0-rc3.tar.gz bff3fb79a53c1d959badde277b10154640901ade75f18b2ff550805748e88fb2 Mail-SpamAssassin-4.0.0-rc3.zip d50f76d1104c5ce82e826f67bb32423236aad8f09cf4b3d3940fd09a94ee22b3 Mail-SpamAssassin-rules-4.0.0-rc3.r1904185.tgz sha512sum of archive files: a72926f30ca8ad14e78fd7a52dc34ce4b871e51e55c5457c0d1998299dcc7cc14dfdebde824cb8b21f027de6ab11bcbb92d8d15514e83017bb76ead9df60d31b Mail-SpamAssassin-4.0.0-rc3.tar.bz2 c41cb8658204583ee5cdc967182fc2cc9fbccbcafb470bb24e8a91c7b2fb409a72ee2967c24be2da90cc21035dd4e9a3852819e712c7b1693a9c976019ea4574 Mail-SpamAssassin-4.0.0-rc3.tar.gz 3d0eb3bc578f93c8f97046ccd98e434f8a4aafb75aa5d93a50a1578c0f9aca093e5e9acaeb1883f39eefa526b11a996d3896f5d90c82b998e26f3a4ed57d690c Mail-SpamAssassin-4.0.0-rc3.zip ea8874a8283d7e2d2e9692388e7a6f07bb7d2fd93fdcf6504de56d0c3b1d5deefdbb99e71f5d9e6941e0b558d5c90bee75a48db837547b2143451685c6c6e4ac Mail-SpamAssassin-rules-4.0.0-rc3.r1904185.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
New Release Candidate 4.0.0-rc2 Testers Needed
Hello Everyone, 4.0.0 release candidate 2 is now available at https://people.apache.org/~sidney/devel It can also be installed from CPAN using tools such as cpanm, e.g. cpanm SIDNEY/Mail-SpamAssassin-4.0.0-rc2-TRIAL.tar.gz This rc fixes all previously open issues targeted for 4.0.0. The issues found and fixed in rc1 were relatively minor, making rc2 look promising for being ready for a full release. Please test and post success or failures as soon as possible. The current draft of the release announcement/notes that has been prepared for the 4.0.0 release can be viewed at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt That file also contains the instructions for how to verify the hashes and GPG signatures of the downloaded files. The extensive document on upgrading from 3.4.x and new features is at https://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE sha256sum of archive files: 9247fa3ec1b731126f8e24093d8cac657010fefd12b5fc9a0e4613b1cc59b4f8 Mail-SpamAssassin-4.0.0-rc2.tar.bz2 317fd6fbdc287171e8f16e30ee19dea0da40ca503847612ec8b4e2e7525cff9a Mail-SpamAssassin-4.0.0-rc2.tar.gz 3d136f8fb1e544e98118884b65d6346b65372863321f332618ee91c4cbf7a58c Mail-SpamAssassin-4.0.0-rc2.zip f3d7165f8a61515a402b3738248c76b343e26ec96b295e1c932f8937a671b8cc Mail-SpamAssassin-rules-4.0.0-rc2.r1903938.tgz sha512sum of archive files: 9ff988fd47047324326d42b787b40fcdbcae03e32956e507fb3050ff3b37c9fc9730945bfc4dff2371df4fa23b35b4ff64882aa3b65989e7fcf86395fa7a3c14 Mail-SpamAssassin-4.0.0-rc2.tar.bz2 65e5084e5488a717e743bcdc68cf17555f0030b67683ae3187411a7421cd903f2cd6417246fdf2ca6d3bc9a7c9982317eda6dffd5ce3cc21f43388aacff0101b Mail-SpamAssassin-4.0.0-rc2.tar.gz fd1d9ef2f9b1d1308ff11949d7dc4735aa55ad8c04bae66e897ee0f179abc0111b149f96520145de00a4e79abfa307717200e69624cfdb852fde333945cacc9a Mail-SpamAssassin-4.0.0-rc2.zip d98f5e2a302479f9d2f144c84a274c3d5ceb8d0a816b6cac640ab194434ef87f6f8d9efde7d498ec9106494a48990e4937dea6e1255edc230979b52b53f82b7b Mail-SpamAssassin-rules-4.0.0-rc2.r1903938.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
New Release Candidate 4.0.0-rc1 Testers Needed
Hello Everyone, 4.0.0 release candidate 1 is now available at https://people.apache.org/~sidney/devel It can also be installed from CPAN using tools such as cpanm, e.g. cpanm SIDNEY/Mail-SpamAssassin-4.0.0-rc1-TRIAL.tar.gz This rc fixes all previously open issues targeted for 4.0.0. Please test and post success or failures as soon as possible. The current draft of the release announcement/notes that has been prepared for the 4.0.0 release can be viewed at https://svn.apache.org/repos/asf/spamassassin/trunk/build/announcements/4.0.0.txt That file also contains the instructions for how to verify the hashes and GPG signatures of the downloaded files. The extensive document on upgrading from 3.4.x and new features is at https://svn.apache.org/repos/asf/spamassassin/trunk/UPGRADE sha256sum of archive files: 5dbcc326e605c85871d6ffb2c930c8b4bd03fb41cfdd93c303b8951377c80acc Mail-SpamAssassin-4.0.0-rc1.tar.bz2 f56567f31b39d79106589bd4e3b890be68c837fb46750cff8380ea2a40b5668a Mail-SpamAssassin-4.0.0-rc1.tar.gz f76ec3a2d357f04f039764df82d00ff49e0e7d05b21ef46e87754d36fd676684 Mail-SpamAssassin-4.0.0-rc1.zip bfc411d5dbcfadf2f3e46b080c6f4e89318bb6349d45d8cec665198ccf39db13 Mail-SpamAssassin-rules-4.0.0-rc1.r1903639.tgz sha512sum of archive files: 931b97b864bba23d7b62b98391fbac7d89152349577d4ceb249e6e20b78664ae88a0adf11e359bde91cc6d84ed81d8df0cd9706cf0b6296c157cfa05406e4b6d Mail-SpamAssassin-4.0.0-rc1.tar.bz2 08fa3d884d4921133b8ce2c80c441773cdfb6cdc935f369b784fee9a6336c05dc7d8bc6009c4bc8c546bbd8ec23dc53bf041caaf21ab780700cd7eaf1f45f95b Mail-SpamAssassin-4.0.0-rc1.tar.gz 4dae781b4b0371901a1c251cc935175ed4458b989083477161bb1a11ed8a7e1fcdd207c47c3d1d9c21205ca01996a9b6241380f80b0f54f1596bc9218808cbe6 Mail-SpamAssassin-4.0.0-rc1.zip f73875263703e7e45cca37ee914a305afbb9d72a4cac56d6810e754eb727277aea1397045a2d8010e303c02e25f736d6fc83ad8702109caad3453a732dffc852 Mail-SpamAssassin-rules-4.0.0-rc1.r1903639.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Request for participation in the 2022 ASF Community Survey
The Apache Software Foundation PMCs have been asked to forward this request to their user and dev communities via their mailing lists: Hello everyone, The 2022 ASF Community Survey is looking to gather scientific data that allows us to understand our community better, both in its demographic composition, and also in collaboration styles and preferences. We want to find areas where we can continue to do great work, and others where we need to provide more support so that our projects can keep growing healthy and diverse. If you have an apache.org email, you should have received an email with an invitation to take the 2022 ASF Community Survey. Please take 15 minutes to complete it. If you do not have an apache.org email address or you didn’t receive a link, please follow this link to the survey: https://edi-asf.limesurvey.net/912832?lang=en You can find information about privacy on the survey’s Confluence page. The last surveys of this kind were implemented in 2016 and 2020, which means we are finally in a position to see trends over time. Your participation is paramount to the success of this project! Please consider filling out the survey, and share this news with your fellow Apache contributors. As individuals form the Apache community, your opinion matters: we want to hear your voice. If you have any questions about the survey or otherwise, please reach out to us! Kindly, Katia Rojas V.P. of Diversity and Inclusion The Apache Software Foundation
In RTC mode, looks like we can go straight to a release candidate
With no votes against, we are now in RTC mode. Committers, please post proposed commits as patches in a Bugzilla issue for review before committing. Hold off on anything that is potentially destabilizing. It looks like the only thing left before we can produce a release candidate is Kevin and Giovanni declaring that the edits to the UPGRADE file on Google Docs are complete so I can reformat it into a text file and commit it to svn. It looks like that is about ready, so I can just go straight to making an rc1 instead of a pre-release 3. RTC rules do not have to apply to edits to documentation, comments, or tests, as long as you are careful to not kill the build with a typo. Thanks everyone, we are almost there! Sidney
Re: Ready to move to RTC mode and produce a pre-3?
Kevin A. McGrail wrote on 20/08/22 6:00 pm: Also, Giovanni and I did a pass on the announcement at https://docs.google.com/document/d/1BGFFfZlQxYe9-H9AyEY_MVski_VtAaTb-4BLA_exwYs/edit and it's ready we believe. The word wrapping will need work when it's brought back to ASCII, sorry. announcements % svn ci -m "Announcement file rewritten for 4.0.0, word wrapped at 72 (Thunderbird's default for plain text), placeholder for file hashes" 4.0.0.txt Sending4.0.0.txt Transmitting file data .done Committing transaction... Committed revision 1903603.
Re: Ready to move to RTC mode and produce a pre-3?
Kevin A. McGrail wrote on 20/08/22 6:00 pm: A pre-release doesn't require RTC so I'd suggest we either 1) use CTR and a pre-3 *or* 2) I'd be +1 for RTC and a rc1. Also, Giovanni and I did a pass on the announcement at https://docs.google.com/document/d/1BGFFfZlQxYe9-H9AyEY_MVski_VtAaTb-4BLA_exwYs/edit and it's ready we believe. The word wrapping will need work when it's brought back to ASCII, sorry. Ok, I'll do the wrap and ASCII conversion on the announcement now. The upgrade file is much longer and Giovanni's done a great job with 19 pages(!!) of upgrades. I've only wordsmithed through the first few pages if anyone has some cycles to help make it better. Sorry, the conversion back to ASCII and word wrapping will be a pain here but best done when the editing is done. My reasoning about RTC and pre3 went like this: It isn't a release candidate unless it has everything done for the release, including the UPGRADE and announcement files. However, I think we are done with everything we want to have in the code, so I am calling for a freeze now so nothing new and unexpected gets casually added while those two document files are finished. If you are happy with the production testing you have been doing and the UPGRADE and announcement files are done, when code freeze starts I'll go straight to cutting rc1, skipping pre3. Otherwise, to make it convenient for testing I'll package the frozen code as pre3 and make rc1 as soon as those two files are ready. Either way, I think we are at a good point for a code freeze. BTW, my concept of RTC is that it is a code freeze that doesn't apply for changes that are only to documentation or comments.
Ready to move to RTC mode and produce a pre-3?
We are down to no more open bugs and sufficient success on the CPAN test machines. My understanding is that testing of trunk in production environments has gone well. If nobody has anything that they are working on that they intend to commit, or any other issues to bring up, I would like to go to RTC mode and I'll then cut a pre-release 3 that people can test with. If that passes a short time for testing I'll cut a release candidate in preparation for actual release. I don't think we need a formal vote. Let's use lazy consensus over the next 72 hours for anyone who has a reason not to switch to RTC to speak up. I'm going to call it 22:22:22 UTC Monday 22 Aug 2022 because that's close enough to 72 hours and it is kind of a cool time and date. -- Sidney
New Pre-Release: 4.0.0-pre2 - Testers Needed
Hello Everyone, 4.0.0 pre-release 2 is now available at https://people.apache.org/~sidney/devel This one has a number of fixes and improvements over 4.0.0pre1. This is the second pre-release for the major release 4.0.0 Please test and post success or failure as soon as possible! The draft release announcement is not yet written. It will include a summary of changes and information for upgrading from 3.4.x. I'll post it here if it is completed before a new release candidate. sha256sum of archive files: a038fbc9b3fb43920a6849e2c089731edcdbe61af2933e58eb29dc3ac602eec6 Mail-SpamAssassin-4.0.0-pre2.tar.bz2 0ba8d27c916a8b63be1aa724b32a72a620852a19131ca1932412c6374e6d595f Mail-SpamAssassin-4.0.0-pre2.tar.gz 71af57cd73bb1e8ae710db8cf01e893d9d27b5431a1394cb5da2eefa92659d25 Mail-SpamAssassin-4.0.0-pre2.zip 74db864800e5caab0747e45a551538a86179f0f15dfef6053ad9449ccaeec453 Mail-SpamAssassin-rules-4.0.0-pre2.r1901380.tgz sha512sum of archive files: e17be9041edefb312221d2b85a729ab24a5fec8a6d2e352354c8fc51c60dcacb71c302b7940e09bc2a7c4a7af46ca288de201d9e84a658f3a23ecad8fac9cf38 Mail-SpamAssassin-4.0.0-pre2.tar.bz2 460d5ea35ac6aaf5d4caf64a345e77dd1d83eccf1e470dc43e54689e698dd8eda62fee18598b96887c6f65264b11db18eeba7f3dd299250d113c198a259f2035 Mail-SpamAssassin-4.0.0-pre2.tar.gz 8005f0a09938074359e1ca9fb716d9c015ca6e8dfb61cbff4713bed4ecefea2abcc753cc27b8078b0c17ce17c8210c1010c730762d61c7632afff6e09065eede Mail-SpamAssassin-4.0.0-pre2.zip 198b8d58233c888395fb95635e4621e7bf403365a1feb61948f055a4522d00cfc61c974b73346ef77cbb8b603221cb30067ea039e74ba9a045e4a4825cd3f526 Mail-SpamAssassin-rules-4.0.0-pre2.r1901380.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: Perlcritic for make test
Henrik K wrote on 10/05/22 4:21 pm:
A quick hack to run it without taint, created t/perlcritic.t which contains:
#!/usr/bin/perl
$ENV{'PATH'} = '/bin:/usr/bin';
-d "xt" && "$^X xt/60_perlcritic.t" =~ /(.*)/ ||
"$^X ../xt/60_perlcritic.t" =~ /(.*)/;
exec($1);
That happened to work with make disttest only because that runs in a
subdirectory below trunk so ../xt found trunk/xt even though it isn't in
MANIFEST. I committed a fix:
Author: sidney
Date: Tue May 10 23:23:31 2022
New Revision: 1900794
URL: http://svn.apache.org/viewvc?rev=1900794=rev
Log:
move percritic test code from xt directory which is not in MANIFEST
Added:
spamassassin/trunk/t/perlcritic.pl (with props)
Removed:
spamassassin/trunk/xt/60_perlcritic.t
Modified:
spamassassin/trunk/MANIFEST
spamassassin/trunk/t/perlcritic.t
Modified: spamassassin/trunk/MANIFEST
...
Re: Perlcritic for make test
Henrik K wrote on 10/05/22 4:21 pm:
A quick hack to run it without taint, created t/perlcritic.t which contains:
#!/usr/bin/perl
$ENV{'PATH'} = '/bin:/usr/bin';
-d "xt" && "$^X xt/60_perlcritic.t" =~ /(.*)/ ||
"$^X ../xt/60_perlcritic.t" =~ /(.*)/;
exec($1);
I submitted a bug report and a PR to Perl-Critic, but I see that their
last commit was in October and they have 33 PRs languishing, so I'm not
holding my breath.
I was about to say that setting PATH would break it when I use plenv or
perlbrew to try out different perl versions, but then I noticed the $^X
which does the job nicely.
Since everything is passing the perlcritic test and it runs so quickly,
I'm +1 about adding it to the tests in t/. If we do that, we could
remove the explicit invocation of it in xt/run_release_test_suite.sh
because it will be part of t/*.t. If perl-critic ever fixes the bug we
can then put the original test in t/ and get rid of the kludge to strip -T.
Re: svn commit: r1900597 - /spamassassin/trunk/t/mkrules_else.t
Thanks, Henrik for this and the other little test things. They were bothering me every time I ran tests the past few days while working on the big test issues, but I had to put off fixing them. Isn't nice when tests produce so little noise that you can finally see the cosmetic or little problems and fix them? h...@apache.org wrote on 6/05/22 5:48 am: Author: hege Date: Thu May 5 17:48:29 2022 New Revision: 1900597 URL: http://svn.apache.org/viewvc?rev=1900597=rev Log: Fix spurious cannot open mkrules_else.0 warnings Modified: spamassassin/trunk/t/mkrules_else.t
New Pre-Release: 4.0.0-pre1 - Testers Needed
Hello Everyone, 4.0.0 pre-release 1 is now available at https://people.apache.org/~sidney/devel It was brought to my attention that it was too early to call the previous one a "release candidate" as we are pretty sure there are still bugs that will show up when this is tried out in serious production. So consider this a pre-release, and do try it out and report those bugs. This one does have a number of fixes and improvements over 4.0.0rc1. This is the first pre-release for the major release 4.0.0 Please test and post success or failure as soon as possible! The draft release announcement is not yet written. It will include a summary of changes and information for upgrading from 3.4.x. I'll post it here if it is completed before a new release candidate. sha256sum of archive files: 7133232e083ea6e6dfa567e8378a0f0c87bad5d948dfb1f5d03cfe5037e8c7ff Mail-SpamAssassin-4.0.0-pre1.tar.bz2 3744b0b020f86eaa9ae2a31c04f771e40a19efdb9a3095fe610fa3db5b5fed59 Mail-SpamAssassin-4.0.0-pre1.tar.gz 3b51c57bd7928414ec0c41c6b40ed9e67f235366da0c6690222e6c0c6865d84c Mail-SpamAssassin-4.0.0-pre1.zip 3ccf879111b4c363c4f72be96e11197cf2e9f97ccd7d5f78b51b65672a92a15a Mail-SpamAssassin-rules-4.0.0-pre1.r1900498.tgz sha512sum of archive files: 14a125ab8a3016034bd9fb976a3840b384a1260e322fa9f76d2691751ad5e1d00118733ccf0ce2bd91a7f49301c2f6e76727b0ab3a43b267aa7d763cc9d45345 Mail-SpamAssassin-4.0.0-pre1.tar.bz2 13e59f9db443b2571afd06464c226d0d8f54d261970d46433057ae3025206952bd0c557fe2a01b281d39d1c7612415d926c921b561b2268f470e0e44faf7e90f Mail-SpamAssassin-4.0.0-pre1.tar.gz cd68a2f7e425669e59e5383d961231c5562546567940f81381e889efa88c2a689f7b2f8551c5651db1654547e48282c2024b391fe784c4f3241d08df5568809b Mail-SpamAssassin-4.0.0-pre1.zip 203839cc054979c450f8c22f179d8868313389a01c9e7b427e8377ef58eb31e809e668aba5d40f4730a8616062bd807b1ba45234b44d015de87c5e22d5534ec2 Mail-SpamAssassin-rules-4.0.0-pre1.r1900498.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Getting ready for a 4.0.0 pre-release
It was pointed out to me that we should be calling the builds "pre-release", we are not yet far enough along for something called a "release candidate". With the build now at the point that make test passes all tests without requiring it be in a checked out svn trunk directory, and no open bugs showing on the 4.0.0 milestone other than one to track the release process, I can build a pre-release 1 any time everyone writing and committing code is at a good pausing point. Henrik, and Giovanni, that means you, as the ones who have been committing things. Can you please post a comment on bug 7981 saying what you want to finish up before I cut a pre-release 1? Once you have finished those things I'll build and (pre)release it. Thanks, Sidney
Re: Back to CTR after all?
Kevin A. McGrail wrote on 1/05/22 6:58 pm: I'd recommend the next build is a prerelease build instead of an RC build until a few people report they are running it in production. I'm working hard to get it into production at PCCC. +1, will do. It's just a name, and a more accurate one in this case.
Re: Back to CTR after all?
Ok, back to CTR we go!
Back to CTR after all?
I'm sorry to jump back and forth on this, but the reasons for being in R-T-C seem to have disappeared. That is something to do when there are no more open bugs before a release and we don't want to make any new bugs. Now it seems that there are bugs for 4.0.0, we expect to find more, and it is likely that bug 7826 will be re-opened before we are done. R-T-C now will just add bureaucracy to fixes that don't need it. I do request that changes to bug 7826 be handled with proper discussion to avoid any potential commit war. I haven't found any official process written for switching between R-T_C and C-T-R. Do I get to just declare that we are back since I declared the switch to R-T-C? Does anyone disagree? Sidney
Re: Problems in make test
Kevin A. McGrail wrote on 1/05/22 3:47 pm: A) When was that MANIFEST change because I do believe there are a couple of items that should be included. I think it's used with ruleqa or something. r1880742 | gbechis | 2020-08-11 02:29:41 +1200 (Tue, 11 Aug 2020) | 2 lines Changed paths: M /spamassassin/trunk/MANIFEST remove rules from MANIFEST that should be downloaded using sa-update B) do any rc's pass make test without a symlink to a trunk checkout to get the rules rulessrc and t.rules? The rest of my followup on this is now in comments in bug 7982, will continue there.
Re: Problems in make test
The instructions in build/README say to only link when doing it in a branch. I did track the problem down to a commit that removed 20_aux_tlds.cf from MANIFEST along with another rules file, saying it should come from sa-update. Even if I put them back, there are still other tests breaking that seem to require one or more rules files that never were in MANIFEST. This seems to be a new problem in 4.0 that only shows up when running make test from a distribution tarball, not from a trunk svn checkout, and so wasn't noticed until now. We can continue this in the new bug comments. Kevin A. McGrail wrote on 1/05/22 2:31 pm: I don't know if you can run a make test on an rc release without doing an ln -s to the rules dir in an svn checkout. If you follow the steps in the build/README file, and there are like three ln -s commands that might help.
Re: Problems in make test
Do you mean 20_aux_tlds.cf? I did install SpamAssassin on the box and ran sa-update. The file is in /var/lib/spamassassin/4.00/updates_spamassassin_org/20_aux_tlds.cf The file is not in the 4_0_0_rc_1 tar. If I run make test in the svn checkout, where the file is in the rules directory, that runs fine. How is make test supposed to find 20_aux_tlds.cf when not run from a full svn checkout? Kevin A. McGrail wrote on 1/05/22 1:39 pm: Sidney, do you have SA rules installed on the box? Might be a chicken/egg issue but sounds like you don't have the 20 TLD files. -KAM -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Sat, Apr 30, 2022 at 9:38 PM Sidney Markowitz wrote: I messed up with make test during the release candidate process. I hope that I just have my setup wrong, because I expect this would have been mentioned before now if everyone gets it. In trunk, or equivalently 4.0.0-rc1, with a clean environment, perl Makefile.PL make make test results in many tests failing after issuing warnings with config: registryboundaries: no tlds defined, need to run sa-update I don't see the same problem doing the same thing in the same environment with the 3.4.6 distribution. Is it just me or does a bug have to be opened? -- Sidney
Problems in make test
I messed up with make test during the release candidate process. I hope that I just have my setup wrong, because I expect this would have been mentioned before now if everyone gets it. In trunk, or equivalently 4.0.0-rc1, with a clean environment, perl Makefile.PL make make test results in many tests failing after issuing warnings with config: registryboundaries: no tlds defined, need to run sa-update I don't see the same problem doing the same thing in the same environment with the 3.4.6 distribution. Is it just me or does a bug have to be opened? -- Sidney
Re: [Bug 7981] New: Remaining tasks for 4.0.0 release
I've created a new issue marked as blocker for the 4.0 milestone as a place to concentrate discussion on remaining tasks for the release that don't fit into other open issues. Sidney
Re: Moving to R-T-C mode for 4.0.0 release - No commits without review
This is wrong, from the point of view of proper process. I'm glad you are accepting "fault", Kevin, "for not being more communicative", but the process is that we have issues that are opened in Bugzilla, work on them is coordinated in the comments of those issues, issues that we decide to include in the 4.0 release are marked with a "4.0" milestone, issues that we decide can be done after the 4.0 release are assigned a "Future" milestone, and we know when we are ready to release when all issues with a 4.0 milestone have been closed. I don't care about being or nor being "communicative". How can anyone on the team be working on an issue and allow the issue to be closed without ever making a comment in Bugzilla and especially without reopening the issue when they see it closed? This is not even a discussion that should be ongoing in this mailing list, other than perhaps a single email saying "Whoops, too soon for a release candidate, I have (re-)opened bug(s) #X and #Y that need more work, look at them for details." Please properly put whatever technical reasons we have to not proceed with the release in the correct Bugzilla issues. This has only reinforced the decision to go R-T-C: I certainly don't want to see this turn into a commit war between everything that Henrik has done in the past days vs an entire independent set of patches completed in the dark in parallel. We can hash it out in Bugzilla comments where it belongs. Sidney Kevin A. McGrail wrote on 1/05/22 4:39 am: The switch to making sure that the patches were without any issues led to significant delays. To my knowledge there is nobody testing the code in any live production systems. I expect we will find bugs because of that. As I said the fault is mine for not being more communicative. But yes right now we have patches doing the same things in different ways with different issues and they need to be reconciled. Appreciate all your help on them. We'll get it done and hopefully I'm wrong with the bugs and gaps being minimal. Regards,. KAM On Sat, Apr 30, 2022, 12:16 Henrik K wrote: Why are you expecting massive issues? I completed all the WLBL work in few days in meticulous detail, there's extensive tests and many people tested it. I think there was about one alias that was missing which Giovanni noticed (cheers). I would have rather not participated, but as you went silent for year or two, why would anyone expect there's some pending diffs. On Sat, Apr 30, 2022 at 12:03:55PM -0400, Kevin A. McGrail wrote: Well it was out fault for working on diffs and not giving visibility. Others then did work on some of the same bugs in a new branch. We are reconciling it against the same work others did on the WLBL, for example. And I expect with RC1 to find some pretty massive issues there since I don't think anybody is using all the code there. We also found some issues with sigonly in the original version and in other patches too. So we're working on bugs and reconciliation between two different people's code fixing the same bugs. Not easy. Hope that clears things up and why I don't think RTC is useful for RC1 because I don't think it has any chance of becoming a full release. Regards, KAM On Sat, Apr 30, 2022, 10:58 Henrik K <[1]h...@hege.li> wrote: Wtf? If you or someone have "giant diffs" or work being done, then post them on the appropriate bugs, reopening if necessary. I don't understand why even waste time posting something vague like this. On Sat, Apr 30, 2022 at 09:50:15AM -0400, Kevin A. McGrail wrote: > Should we delay RTC? I know there are some bugs being worked on in some of the > bugs that have been closed. I also know there's some patches that Giovanni > might or might not have gotten to for the WLBL. We had a giant diff for that > was collided. > > On Sat, Apr 30, 2022, 05:55 Axb <[1][2]axb.li...@gmail.com> wrote: > > Doh! Henrik already did it. > Thanks! > > On 4/30/22 11:52, Axb wrote: > > Should we update [2][3]20_aux_tlds.cf for this relesase? > > > > I can't do it at the moment - any taker? > > > > On 4/30/22 11:27, Sidney Markowitz wrote: > >> It's time for a code freeze in preparation for the release of 4.0.0 > >> release candidates. > >> > >> Please do not commit anything to trunk other than the usual ongoing > >> rules stuff that finds its way into the rule update process. > >> > >> Any new bug fixes that need to be committed for 4.0.0 should be > >> associated with a bug opened with a 4.0 mileston
New Release Candidate: 4.0.0-rc1 - Testers Needed
Hello Everyone, 4.0.0 release candidate 1 is now available at https://people.apache.org/~sidney/devel This is the first release candidate for the major release 4.0.0 Please test and post success or failure as soon as possible! If these files don't show any immediate problems I'll call for a vote on moving to full release. The draft release announcement is not yet written. It will include a summary of changes and information for upgrading from 3.4.x. I'll post it here if it is completed before a new release candidate. sha256sum of archive files: 3ca9fe54aebc641ca20864af7087d6a8a6047215f03164ad891662268692d9cf Mail-SpamAssassin-4.0.0-rc1.tar.bz2 b32ba0dcd5972dbb32c7f8c30baaeb9f7b94aa1c23face35a7aefb6e7a2e0f77 Mail-SpamAssassin-4.0.0-rc1.tar.gz abe71edd81e13290234bcdc4a67556530aa1b2b36bfb9e1f9825eeb8e2cf1512 Mail-SpamAssassin-4.0.0-rc1.zip 0192e3aba11a917626d7327995537cdd7a5f65a9aedecdc959b9a26bacb6d08f Mail-SpamAssassin-rules-4.0.0-rc1.r1900354.tgz sha512sum of archive files: a91256f05edabe8d69aeec903de35ce9398463fafdd5702c5d10f441ff0f1876382ccd97543f864efaf0e0df549a280f113203a14fb12eeb8f039aa3ce602956 Mail-SpamAssassin-4.0.0-rc1.tar.bz2 fd990192a00ab040eeb53334e4811e6a666aacbb0f45e86f5a74b09fe4104dce366cfaad947446b0ed30fdafee01720507cd76e88a7372e026f414a43bee7eb7 Mail-SpamAssassin-4.0.0-rc1.tar.gz e6efafa3377f7ea1b881fe70c7bb446761dac9512d601bcd351901a5ba778537583025dbbafa57fe85345f17b3c101842043f83744eb2de5c4ea6b1916a5e350 Mail-SpamAssassin-4.0.0-rc1.zip d2f2ff7847a022ce88e77ff91e2990138723fbe1e6632407e07b823177c14fdc7ffc356a612e2d828ebfc3397d3e99bb266e606e03b764972ef3032b93d42329 Mail-SpamAssassin-rules-4.0.0-rc1.r1900354.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Moving to R-T-C mode for 4.0.0 release - No commits without review
It's time for a code freeze in preparation for the release of 4.0.0 release candidates. Please do not commit anything to trunk other than the usual ongoing rules stuff that finds its way into the rule update process. Any new bug fixes that need to be committed for 4.0.0 should be associated with a bug opened with a 4.0 milestone and get reviewed before committed. Please hold off on committing for any issue that is not marked as 4.0 milestone. Thanks, Sidney
Re: Preparing a 4.0.0 release
Henrik K wrote on 30/04/22 6:13 pm: Shall we start rolling rc's out, all bugs are closed? That's fine with me. I'll start making one while checking whether an rc needs a vote to be official. If anyone can think of anything else that should be done before there is a release candidate, speak up now. Sidney
Re: Preparing a 4.0.0 release
David Bürgin wrote on 23/04/22 5:32 am: Have you considered migrating to Git before the next major release? It has many advantages over Subversion, and would make development more accessible and transparent for other developers. I personally prefer working with git as compared to svn, but I agree with Henrik that it would not provide enough benefits in this case to switch right now. We are close to finally getting 4.0.0 out the door, a goal that has been delayed for too many years. If anything, even considering something major like switching our development processes from svn to git, and presumably changing from Bugzilla to using Github for tracking, PRs, testing, and release processes, would come after the big milestone of the 4.0.0 release, not just before.
Preparing a 4.0.0 release
We are down to six open issues on Bugzilla with a 4.0 milestone, none listed as blockers. Let's see if we can get a release out. I'll take care of the release manager duties. Henrik volunteered to spend some time wrapping up issues during the next few weeks. Of course anyone else can help too. One possible loose end I noticed is that there are some open issues with milestone "Undefined", seven of which are Priority 2, Severity Major. That's a small enough number that it should be easy to scan and at least verify that none of them are of interest for 4.0.0. Regards, Sidney
Re: Rule updates are too old - 2021-04-13 3.3.0:2021-04-12 3.3.1:2021-04-12 3.3.2:2021-04-12
Aside from anything else about this, we are overdue implementing the phase-out of sha1 hashes in rule updates and the freezing of pre-3.4.2 rule update files to the last one published with sha1 hashes. dar...@chaosreigns.com wrote on 13/04/21 11:00 pm: SpamAssassin version 3.3.0 has not had a rule update since 2021-04-12. SpamAssassin version 3.3.1 has not had a rule update since 2021-04-12. SpamAssassin version 3.3.2 has not had a rule update since 2021-04-12. 20210412: Spam and ham are above threshold of 150,000: http://ruleqa.spamassassin.org/?daterev=20210412 20210412: Spam: 636925, Ham: 273430 The spam and ham counts on which this script alerts are from http://ruleqa.spamassassin.org/?daterev=20210412 Click "(source details)" (it's tiny and low contrast). It's from the second and third columns of the line that ends with "(all messages)" The source to this script is http://www.chaosreigns.com/sa/update-version-mon.pl It looks like both the weekly and nightly masschecks need to have sufficient corpora in order for an update to be generated.
ANNOUNCE: Apache SpamAssassin 3.4.6 available
t reaches your mailbox, while allowing other components of a mail system to act on its results. Most of the Apache SpamAssassin is written in Perl, with heavily traversed code paths carefully optimized. Benefits are portability, robustness and facilitated maintenance. It can run on a wide variety of POSIX platforms. The server and the Perl library feels at home on Unix and Linux platforms and reportedly also works on MS Windows systems under ActivePerl. For more information, visit https://spamassassin.apache.org/ About The Apache Software Foundation Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 100 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 2,500+ contributors. For more information, visit https://www.apache.org/ -- Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
New Release Candidate: 3.4.6-rc1 - Testers Needed
Hello Everyone, 3.4.6 release candidate 1 is now available at https://people.apache.org/~sidney/devel This fixes a small but an annoying bug that was introduced in 3.4.5, plus one more minor bug that was simple enough to include once we knew we needed a version 3.4.6. Please test and post success or failure as soon as posible! If these files don't show any immediate problems I'll call for a vote on moving to full release. The draft release announcement has been committed to the 3.4 branch in build/announcements/3.4.6,txt Suggest changes to the summary of fixes if necessary. sha256sum of archive files: d5cf1db15acf3664f4f7a330d4c23aa928afccfb14ae4bac1c6153b65f202767 Mail-SpamAssassin-3.4.6-rc1.tar.bz2 8964d5af97e3225b34319ac56888ea39a5c898d44d81d82465458fd995f9c84b Mail-SpamAssassin-3.4.6-rc1.tar.gz 92bd5b57cfc8ea71bc1b37d85da182f00d921fc9e86f63f8f4f15b1b2199a5fa Mail-SpamAssassin-3.4.6-rc1.zip e5a800dfb891ba5b48c84ac3db382d6b848d41064ca1e0da666abac4d110e0f9 Mail-SpamAssassin-rules-3.4.6-rc1.r1888465.tgz sha512sum of archive files: c9dbf26c24cc0abb5eaa7370d162b16eb7ef1ce30e4c4175c910bcacd8a304192b7325775cb5df66ce3341af4d8c01c7852ae0929f0225429edf692bd3905525 Mail-SpamAssassin-3.4.6-rc1.tar.bz2 ae1874d429cb93326c5077dbd820d7ab583e24c4bd61ca79cf9d4868894a67a109d16d4bf229aa1b2d3bca7b0856440ebd182d05db704a94c2499e21ecf13487 Mail-SpamAssassin-3.4.6-rc1.tar.gz e509dcb01138b15fc1757bb48b69e9034690a7f4037f2538086af27e40d887e6f8f9b8ddd54149687a20e6784cc0f93f8868c6d7f6ae5cc17bc58fcb71bd630f Mail-SpamAssassin-3.4.6-rc1.zip 7f9189a7ecaf425a9fbebfcda1795499b8bc7ab6d4e8e672706bb5b1c21525a9d999e8f64a8fb8d20b85b6f220fca4f6c0424bdafface9d265f62d02dda3c4a2 Mail-SpamAssassin-rules-3.4.6-rc1.r1888465.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: Preparing 3.4.6 release - Branch now in RTC mode
Henrik K wrote on 8/04/21 4:46 pm: Could we also add 7892 in, as it's 100% trivial and safe change? https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7892 Then the other one I marked, which is not as trivial. It will rarely add an extra wrong DNS query, which could by fixed by uridnsbl_skip_domain in case of FPs. I'd vote to just skip it. https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7891 Ok, I vote +1 to commit the 7892 fix to 3.4 branch. We need a third vote to do it. If you think 7891 should be skipped for 3.4.6, then I'll go along with skipping it. Can one more committer jump in with a vote on 7892 after reviewing the patch? I'm ready for a build of rc1 other than that. Sidney
Re: Test failures in 3.4 branch
Bill Cole wrote on 8/04/21 3:33 pm: The string T_KHOP_BOTNET_4 (apparently a rule name) does not occur anywhere in the 3.4 branch or in trunk. Theory: it's seeing a bogus rule file that isn't in the distribution. Maybe a user_prefs file? After carefully ensuring that trunk was a clean checkout, it all worked, so I guess I had some svn ignored files in rules and/or rulesrc that affected the testing without showing up in svn status. All ok now, on with the release process.
Test failures in 3.4 branch
Here are failures I got running in the 3.4 branch with the rules, rulesrc, and t.rules symlinked to trunk. sudo make test TEST_FILES="xt/*.t" in macOS 11.2.3 I'm not deep enough into the code to address the issue right now, just following release steps. Can someone please look at this and comment? xt/50_lang_lint.t ... Apr 8 12:24:46.964 [94600] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:47.821 [94600] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 1/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:48.646 [94602] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:49.292 [94602] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 2/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:50.076 [94604] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:50.710 [94604] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 3/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:51.497 [94606] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:52.141 [94606] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 4/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:52.946 [94608] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:53.591 [94608] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 5/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:54.369 [94610] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:55.014 [94610] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 6/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:55.814 [94612] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:56.466 [94612] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 7/? # Failed test at t/SATest.pm line 811. Apr 8 12:24:57.255 [94614] warn: config: invalid meta T_KHOP_BOTNET_4 token: .8 Apr 8 12:24:57.918 [94614] warn: lint: 1 issues detected, please rerun with debug enabled for more information Not found: anything =at t/lang_lint.t line 19. xt/50_lang_lint.t ... 8/? # Failed test at t/SATest.pm line 811. # Looks like you failed 8 tests of 8. exec failed at xt/50_lang_lint.t line 6. xt/50_lang_lint.t ... Dubious, test returned 2 (wstat 512, 0x200) Failed 8/8 subtests - Sidney
Preparing 3.4.6 release - Branch now in RTC mode
I already mentioned this in another thread, repeating it with a suitable Subject for clarity. It looks like we will release version 3.4.6 to fix bug 7897 that is a regression introduced by the fix for bug 7822. The proposed fix will revert to the bug 7822 incorrect behavior, which is considered less important and can be addressed in trunk for the 4.0 series. The 3.4 branch is now in code freeze, i.e. in RTC mode, other than the commits that are part of the release process by the release manager (me). I'll proceed with building a 3.4.6-rc1 which we can vote on, rebuilding and releasing 3.4.6 as soon as we get a release candidate that passes the votes. Sidney
Re: ANNOUNCE: Apache SpamAssassin 3.4.5 available
Bill Cole wrote on 8/04/21 10:09 am: I believe we should release a 3.4.6 in the near term (days not months) to fix 7897 even if we have to do it with 7822 unfixed. I'd rather both were fixed but I don't have the free cycles right now to get a good enough understanding of the entanglements to fix it myself. Ok, I'll start the release process, with me as release manager. We are now back to code freeze, RTC mode in the 3.4 branch. If anyone thinks that there is a safe fix for bug 7822 to go along with this, speak up. Otherwise we'll release 3.4.6 with the only changes being the patch to fix 7897 that reverts 7822. As per our processes, I can proceed with preparing the release and we vote when there is a build to vote on. Could one of you who does have the deeper understanding of the issues write the brief (one line?) descriptions of what is being fixed and what is being regressed as it should appear in the release notes for 3.4.6? Thanks, Sidney
Re: ANNOUNCE: Apache SpamAssassin 3.4.5 available
Henrik K wrote on 7/04/21 1:31 am: I think we should release 3.4.6 because of this bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7897 Metas depending on uribl rules do not currently hit.. :-( Though it seems there aren't any metas in stock ruleset that are affected. I do have on my own rules. So dunno, what is the timeline for a 4.0 release.. Henrik, are you saying that this isn't enough reason to release 3.4.6 after all because it doesn't effect any metas in stock ruleset? I'm ok with doing the release manager work for 3.4.6 if there is consensus that it is necessary. Also, to be clear, is bug 7897 more important to fix than the bug 7822 that would be re-introduced by reverting its patch? Sidney
Can anyone help get a Windows build working?
SpamAssassin has not had working instruction for building under Windows since version 3.4.1 and ActivePerl's switch to using dmake. It looks like an alternative should use Strawberry Perl but what we have now fails to build with it. Does anyone here have the Windows experience and inclination to take a look at getting SpamAssassin to build under Windows, preferably using Strawberry? The obsolete instructions using ActivePerl are on the wiki InstallingOnWindows page at https://cwiki.apache.org/confluence/x/khcgBw
[CVE-2020-1946] Apache SpamAssassin malicious rule configuration (.cf) files can be configured to run system commands
Apache SpamAssassin 3.4.5 was recently released [1], and fixes an issue of security note where malicious rule configuration (.cf) files can be configured to run system commands. In Apache SpamAssassin before 3.4.5, exploits can be injected in a number of scenarios. In addition to upgrading to SA 3.4.5, users should only use update channels or 3rd party .cf files from trusted places. Apache SpamAssassin would like to thank Damian Lukowski at credativ for ethically reporting this issue. This issue has been assigned CVE id CVE-2020-1946 [2] To contact the Apache SpamAssassin security team, please e-mail security at spamassassin.apache.org. For more information about Apache SpamAssassin, visit the https://spamassassin.apache.org/ web site. Apache SpamAssassin Security Team [1]: https://s.apache.org/ng9u9 [2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-1946 -- Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
ANNOUNCE: Apache SpamAssassin 3.4.5 available
r architecture that allows other technologies to be quickly incorporated as an addition or as a replacement for existing methods. Apache SpamAssassin typically runs on a server, classifies and labels spam before it reaches your mailbox, while allowing other components of a mail system to act on its results. Most of the Apache SpamAssassin is written in Perl, with heavily traversed code paths carefully optimized. Benefits are portability, robustness and facilitated maintenance. It can run on a wide variety of POSIX platforms. The server and the Perl library feels at home on Unix and Linux platforms and reportedly also works on MS Windows systems under ActivePerl. For more information, visit https://spamassassin.apache.org/ About The Apache Software Foundation Established in 1999, The Apache Software Foundation provides organizational, legal, and financial support for more than 100 freely-available, collaboratively-developed Open Source projects. The pragmatic Apache License enables individual and commercial users to easily deploy Apache software; the Foundation's intellectual property framework limits the legal exposure of its 2,500+ contributors. For more information, visit https://www.apache.org/ -- Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
John Hardin wrote on 18/03/21 1:48 pm: Are there guidelines for how to (not) comment on the commit that fixes a CVE? Blocking public access to a bug doesn't help obscure the fix if the public comment on the fix commit is referencing a locked security bug... What kind of comment would that be? Discussion about the bug would be in the comments of the Bugzilla issue and in the securty@ mailing list, both of which have restricted access (the Bugzilla issue being security restricted in this case). The only public comment is the commit log message, which is in public view and is sent to commits@. The policy is to not mention the CVE id in that commit message and to say something bland but true like "fixing rule parsing". Oh, are you saying to be more explicit in the part of the policy about how to write those commit messages and what to say in public about the commit? Yes, that would be a good idea.
Rewrite of SecurityPolicy page on SpamAssassin wiki
I've completely rewritten the wiki page describing our project's process for handling reports and fixes of security vulnerabilities because it did not match what we actually do. https://cwiki.apache.org/confluence/display/SPAMASSASSIN/SecurityPolicy I have a point I would like to bring up for discussion. "Also, unlike non-security issues which are closed in Bugzilla once the fix is committed, leave this issue in Open state until the SpamAssassin release containing the fix is prepared. That prevents people without full access to the issue from matching up the time of closing of the issue with time of svn commit." That is something we have done, but I don't see the need given that for anyone without access to security bugs any search or notification of closed bugs will not show the issue. Even if someone knows the issue number, attempting to look at it will show that a closed-access issue with that number exists, but nothing about its contents or status or dates the status changed. Given that the security purpose for that policy is not actually helped by it, and it is more convenient to close bugs when the fix has been tested and committed, I propose that we drop that policy. After getting some responses to get a sense of things, I'll call for a vote to change the policy. I also locked the page to allow it to be viewed by anyone, but edited only by members of the PMC. We might want to consider identifying other wiki pages that similarly describe PMC policies and lock write access to those too. While it is helpful that a wiki page can be improved by anyone who notices a typo or awkward phrasing, pages that purport to describe official policy should have a bit more assurance that they remain accurate. If anyone thinks that was a wrong decision, feel free to speak up and we can discuss and vote on it. Sidney
Next steps in the 3.4.5 release
Hi everyone, It's awfully quiet regarding the testing of 3.4.5-rc2. I'm making some assumptions in taking the next steps in the final release. Please, speak up if any of these assumptions are wrong and we should not go on to a quick 3.4.5 build and vote. I assume: 1. There are people who have been running branch 3.4 in a production environment since at least when it was tagged as 3.4.5-rc1 last January (even though there was no announcement of 3.4.5-rc1 builds) 2. The few commits to two minor issues that were committed since then have been sufficiently reviewed and are deemed safe. 3. Enough committers do think that what we have in 3.4.5-rc2 is ready for release so nothing is left in the process except to build 3.4.5 and call for a release vote. 4. Nobody has a -1 vote against proceeding with release that they can explai with a technical reason. I'll give this another two days. If there are no negative responses to consider, I'll proceed with the next steps in the release by building what we currently have as 3.4.5. Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org sid...@sidney.com
New Release Candidate: 3.4.5-rc2 - Testers Needed
Hello Assassins, 3.4.5 release candidate 2 is now available at https://people.apache.org/~sidney/devel There is a CVE fixed in 3.4.5 that we will disclose more at release so you'll definitely want to look at upgrading. Please test! This branch of the code has been tested enough that if these files don't show any immediate problems I'll call for a vote on moving to full release. sha256sum of archive files: befd4d969090a416c9f5537d25d7b8d96bc7b7738683caa2f7e980335dc2bc7c Mail-SpamAssassin-3.4.5-rc2.tar.bz2 12fd83cb58d9e9cb92356e835d11f884d981e11bf00e95470c050295282dfaee Mail-SpamAssassin-3.4.5-rc2.tar.gz 9420b96a8e911b0f00410a759a28b18a0be00ffd2e83b14781ff3c6a667b9dec Mail-SpamAssassin-3.4.5-rc2.zip c83f16e2b264296f1df56b33b17c5fca7783be5bd3d2347f7b26a56a9013f37f Mail-SpamAssassin-rules-3.4.5-rc2.r1887567.tgz sha512sum of archive files: baf0a8987c48ae819b027e19cf7a9b2a96a06b382a5c6405cc196cb752c71a93811e7a131fe1eb41f3da3f2fe4ba9f7742aa8404cb96c42f31f316297a5d6aa9 Mail-SpamAssassin-3.4.5-rc2.tar.bz2 77cc9e2f9d8ba679a860db1b8340d7773abded5dbad9e2288f3e8736c64d0df0feac6bdf7b1141e75fee42fb38e1d23a507d87f14eb717282181158e8641d3a7 Mail-SpamAssassin-3.4.5-rc2.tar.gz 9dc89eb432a0654870e08e8c47f588025f745ee145d3617353fe5585cc92d51b03743561ea39deb8e5517c69fd88e8a5e60250a2eecc90562b39db847fda7e43 Mail-SpamAssassin-3.4.5-rc2.zip 232ffbe97b2b72b824cb7df12dc43dbb58bdcc328cbbd048aaf2ab0e6044e6637b647920a4b6f1cabec2bb4c89e84cf00cd0852ac0b171175f443c8ad1d2 Mail-SpamAssassin-rules-3.4.5-rc2.r1887567.tgz Fingerprints of keys for gpg signatures in the .asc files: Install files: D8099BC79E17D7E49BC21E31FDE52F40F7D39814 Rule files:5E541DC959CB8BAC7C78DFDC4056A61A5244EC45 Regards, Sidney Markowitz Chair, Apache SpamAssassin PMC sid...@apache.org
Re: svn commit: r1887691 - /spamassassin/trunk/build/README
Benny Pedersen wrote on 16/03/21 5:46 pm: On 2021-03-15 23:32, sid...@apache.org wrote: + pyzor + razor why in build stage ? :( we would love to see no plugins enabled pr default, and if wanted enabled make guides on what to do for enable it imho would be more helpfull, i say this as a gentoo repo maintainer They are used for running the tests, which is part of our release build process, which that file documents. As a gentoo repo maintainer I would expect that you can figure out what to modify for your own packaging. Now that you mention it, however, I can see that it could be a good idea to separate out the list of what is needed for the actual build steps that are described later in the file. The first part of the file describes how to make sure that we have everything in the repo ready to build, up to the point of tagging the repo with the release version number. The steps after that describe making a clean checkout of the tag into a new directory and building an install package from that. Since that could even be done on a different computer, it is reasonable to separate the dependencies of just that part, which as you point out should not require pyzor or razor. Sidney
Preparing for 3.4.5 release - 3.4.5-rc2 on its way
KAM has passed the mantle of release manager for 3.4.5 to me for the final steps, and I'm preparing a 3.4.5-rc2 now. When it is available, I would like everyone who can to give it a quick test so we can move on to a vote as soon as possible about approval to rebuild it as a release 3.4.5. To that end, I have committed a draft of the announcement text and would appreciate it get reviewed ASAP: trunk/build/announcements/3.4.5.txt I've noted in the announcement that we intend to have no more development, bug fixes, or releases in the 3.4 branch unless another sufficiently important security issue requires it. Committers, since this is documentation, not code, and in any case not in the 3.4 branch, that file is not subject to the RTC code freeze 3.4 is now under. Thanks, Sidney Markowitz Chair, Apache SpamAssassin PMC
Re: Freeze on 3.4 branch (RTC mode)
Benny Pedersen wrote on 10/03/21 6:41 pm: is minimal version of Mail::DKIM raised ? It still set in Makefile.PL to minimum version 0.31 recommended 0.37. Is there a Bugzilla issue for the problem you have described? I'm afraid I don't know much about DKIM. Nothing new will be going into 3.4.5 unless there is an open bug that is voted as being a blocker for the release. There are no open blockers now, and I hope that the release can be out very soon. It would help if you could describe your problem in a Bugzilla issue in clear enough terms and examples that it can be reproduced by someone who is more familiar with DKIM and perhaps amavisd or dkimpy or fuglu. Sidney
Freeze on 3.4 branch (RTC mode)
We have to release 3.4.5. There have been three commits since the final preparation of 3.4.5-rc1, including the fix for the AskDNS bugs and 7875. Those seem safe enough to include in a release. Please don't commit to the 3.4 branch without a review and vote (RTC mode), which should only happen if something is found that would block the release. Regards, Sidney
Apache SpamAssassin Looking for Student Developers and Project Ideas for Google Summer of Code 2019
On behalf of the Apache SpamAssassin PMC, we are supporting the Google Summer of Code for 2019. GSOC is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school. Please help spread the word, review bugzilla, and post about great project ideas that might be appropriate for a student developer with an Apache mentor guiding them. As examples, here is one project that has already been picked up for this year, but gives an idea of what we are looking for https://s.apache.org/YS0r and a list of ideas that were suggested for GSOC-2018 that could still be done https://s.apache.org/NIKo We want to make sure nothing is missed this year. And maybe a student developer wants to take the torch on one of these proposals! PLEASE: If there are student developers posting on users@ or dev@, please take extra care to guide them and be nice! More info: https://summerofcode.withgoogle.com/ and (READ THIS ONE BEFORE APPLYING) https://community.apache.org/gsoc.html Sidney Markowitz sid...@apache.org Chair, Apache SpamAssassin Project Management Committee
Apache release policy
I opened https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7596 and want to make sure it is noticed in time for our next release. We are required to use SHA-256 or SHA-512 checksums for our distribution downloads, and to not use SHA-1. I don't see any reason to use SHA-512 instead of or in addition to SHA-256. Sidney
Congrats to new ASF Member: Karsten Braeckelmann
Hi everyone, This week's announcement of the new Members elected during the annual ASF Members' Meeting includes one from our very own SpamAssassin PMC, Karsten Braeckelmann! https://s.apache.org/D6iz Please join us in congratulating Karsten on becoming an ASF member! Thanks, Sidney Markowitz Chair, Apache SpamAssassin PMC
REMINDER - TAC Applications closes in 2 weeks for ACNA Montreal
[Forwarded by the PMC on request of the Travel Assistance Committee] Reminder that travel assistance applications for ApacheCon NA 2018 are still open but only for another 2 weeks! Please get your applications in NOW. We will be supporting ApacheCon NA Montréal, Canada on 24th - 29th September 2018 TAC exists to help those that would like to attend ApacheCon events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < http://www.apache.org/travel/ >. Applications are now open and will close 1st May. Important: Applications close on May 1st, 2018. Applicants have until the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful awards shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds. We therefore encourage (as always) anyone thinking about sending in an application to do so ASAP. We look forward to greeting many of you in Montreal Kind Regards, Gavin - (On behalf of the Travel Assistance Committee)
ApacheCon NA 2018 Travel Assistance Applications now open!
Hi everyone, The Travel Assistance Committee has asked the various Apache Project Management Committees to forward the following announcement to the user and dev mailing lists: --- The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for ApacheCon NA 2018 are now open! We will be supporting ApacheCon NA Montreal, Canada on 24th - 29th September 2018 TAC exists to help those that would like to attend ApacheCon events, but are unable to do so for financial reasons. For more info on this years applications and qualifying criteria, please visit the TAC website at < http://www.apache.org/travel/ >. Applications are now open and will close 1st May. Important: Applications close on May 1st, 2018. Applicants have until the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful awards shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds. We therefore encourage (as always) anyone thinking about sending in an application to do so ASAP. We look forward to greeting many of you in Montreal Kind Regards, Gavin - (On behalf of the Travel Assistance Committee)
Re: Wiki edit access please
Bill Cole wrote on 3/02/18 6:33 AM: > username: BillCole > > Why: I keep finding wrongness/staleness that I want to fix. > > If there's a way for committers to enable this for ourselves, I'm too > clueless to find it... I added you to the AdminGroup on the wiki, so now you can fill requests like that too. It isn't automatic for committers. When you want to give someone edit access to the wiki, add their name to the ContributorsGroup page, which you can now see and edit. Sidney
Apache SpamAssassin Looking for Student Developers and Project ,Ideas for Google Summer of Code 2018
On behalf of the Apache SpamAssassin PMC, we are supporting the Google Summer of Code for 2018. GSOC is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school. Please help spread the word, review bugzilla, and post about great project ideas that might be appropriate for a student developer with an Apache mentor guiding them. For example, due to a hiccup with missing a deadline, this proposal in 2015 wasn't able to be done (Sorry, Sarang!). https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7287 We want to make sure nothing is missed this year. And maybe a student developer wants to take the torch on that proposal! PLEASE: If there are student developers posting on users@ or dev@, please take extra care to guide them and be nice! More info: https://summerofcode.withgoogle.com/ and (READ THIS ONE BEFORE APPLYING) https://community.apache.org/gsoc.html Sidney Markowitz sid...@apache.org Chair, Apache SpamAssassin Project Management Committee
All ported
I'm done with the patches. I verified that I included all the patches you sent (except the one for Bug 7215 that Kevin G sent, as it looks like we are not including that in 3.4.2), and checked again that any files that are different in branch and trunk that I did not port only have the unicode changes that we are not releasing in 3.4.2. I did not touch the following rules files even though there are differences between what they contain in branches/3.4 and in trunk. 20_dnsbl_tests.cf 20_drugs.cf 20_freemail.cf 20_freemail_domains.cf 20_imageinfo.cf 20_ratware.cf 25_uribl.cf Sidney
My error on Bugzilla bugs this weekend
My apologies to all - I just noticed that I have been using the Version field in Bugzilla all this weekend when I should have been using Target Milestone. Now I need to go back to whatever I changed and correct it. Sidney
Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing
Kevin Golding wrote on 15/04/17 8:51 PM: > Apologies if any overlap This looks good. I can see from the names of the attachments that most if not all will be ones I have yet to look at, so the timing is good. I'll grab the attachments and continue from there for the rest of tonight. Thanks, Sidney
rules/*.cf in syncing 3.4 and trunk
Are any of these relevant for syncing 3.4 with trunk, or are only the files in trunk used for rule updates? These are the files in the rules directory that have differences between trunk and the 3.4 branch: 20_dnsbl_tests.cf 20_drugs.cf 20_freemail.cf 20_freemail_domains.cf 20_imageinfo.cf 20_ratware.cf 25_uribl.cf 50_scores.cf
Syncing 3.4 and trunk
Kevin, this question is probably for you. Should I apply thge last four changes to rules/50_scores.cf that were made in trunk to the 3.4 branch? Only the first of them mentions a bugzilla issue in the commit message, bug 7282, but I think they are all part of it and that it makes sense to port. Also, I'm porting bug 7192 which looks like it was incorrectly labeled with a 3.4.1 version even though it was committed after the 3.4.1 release, and then never ported to the branch. The commit for that in trunk created a file in your sandbox sandbox/kmcgrail/20_rules_to_sandbox.cf Do I put that in branch/3.4 also, or skip that file? Sidney
Re: PROPOSAL: Be stricter about creating Bugzilla issue before committing
Kevin A. McGrail wrote on 15/04/17 3:06 PM: > Plus one here but will note Kevin Golding and I have already been syncing > trunk and 3.4. I can email you the remaining work tomorrow so we can sync. I noticed what you have done. So far I'm about to be done with all the non *.pm files and there are only 22 *.pm files with differences left to look at. If you and Kevin Golding have anything that you are in the middle of that you have not yet committed you should let me know because I may be able to get through all the rest by tonight (still afternoon here). Sidney
PROPOSAL: Be stricter about creating Bugzilla issue before committing
My task this weekend has been tracking down mismatches between trunk and branch 3.4 to make sure that anything that has been committed to trunk and is or should be targeted for the 3.4.2 release has been committed to the branch. In doing that I'm encountering a number of commits to trunk that do not refer back to a Bugzilla issue. Usually it is a simple and obvious patch for an issue that clearly ought to be done, and probably didn't seem worth the extra steps of creating an issue in Bugzilla for it. Maybe some of them were a result of the committer not including the bug number in the commit message - I would not be able to tell if that's the case without a search in Bugzilla in which I guess the keywords to look for. I propose that we make a practice of 1) Create a Bugzilla issue for anything we commit to source files or to any other files that are part of the build process; 2) Include the text "bug " somewhere in the commit message. The benefits of doing this include 1) Makes it easier to track what has to be ported from trunk to branch before a release; 2) Makes it possible to look up the reasons and discussions related to a commit, and to find other commits that are related to the same issue even when at the time of the first commit it was not anticipated that there would be anything more to be committed. We already have in our guidelines to include "bug " in the commit message https://wiki.apache.org/spamassassin/UsingBugzilla#Committing_Fixes_For_Bugs I would like to see if there is consensus on adding to our guidelines that we always create a Bugzilla issue for something that will be committed into our source or related files. It also seems like a good idea to create a CommitterGuidelines page on the wiki. I had some difficulty finding the guideline for svn commit messages where it is hiding under UsingBugzilla. Comments, votes? Sidney
Re: Need a Volunteer to help unifying trunk and 3.4 branch
Kevin A. McGrail wrote on 11/04/17 4:16 PM: > Any chance you can look at bug 7181 and why sa_compile.t fails? Fixed.
Re: Need a Volunteer to help unifying trunk and 3.4 branch
Kevin A. McGrail wrote on 11/04/17 4:16 PM: > Any chance you can look at bug 7181 and why sa_compile.t fails? You > need re2c installed on the machine. I'll look at. > > Also a pass through bugs and blockers in bugzilla would be cool to make > a list of bugs we want to close in the next 2 weeks or that you think > are a must fix for 3.4.2. I'll do a pass, but we really should have it looked at by people here who are more actively working with mail servers every day and would have a good feel for how important or not a bug is. You know who you are :) Can you jump in and do at least a quick pass over the open bugs for some triage? Thanks, Sidney
Re: Need a Volunteer to help unifying trunk and 3.4 branch
Kevin A. McGrail wrote on 10/04/17 1:51 PM: > Hi, > > I'm working on the 3.4.2 RC and I was wondering can step forward and get > trunk and 3.4 into better sync? I've got a pretty long weekend coming up, I'll see how much of it I can get done. Sidney
Mass check and rule updates - Down for machine migration
We are in the process of migrating off old machines to a new one for the masschecks and rule update processing. Unfortunately the required shutdown of the old machines has happened before everything was complete on the replacement. The existing data is safe and is being migrated. However submission of new masscheck data and generation and download of rule updates are not running until the new machine is brought up. I don't have a specific ETA for the new machine right now, just the assurance that the work is in progress. I'll post more details when I get them. Regards, Sidney
Re: Secondary DNS Changes - update needed on your end.
Benny Pedersen wrote on 13/08/16 6:21 AM: > not all eggs in one basket for me :=) > If ASF Infra has properly set everything up they would not have all their eggs in one basket. To stretch the metaphor way more than it should be... Right now we have the eggs in a couple of baskets (sonic.net and hyperreal.org). If ASF Infra provides DNS services for projects then we can ask them to carry our eggs for us in whatever multiple baskets they have set up. Sidney
Re: Secondary DNS Changes - update needed on your end.
Axb wrote on 13/08/16 1:30 AM: > This dates post-McAfee, pre-Apache days so it goes way back. Oh, pre-Apache! Now it finally makes sense to me why it is set up like it is. In any case I have asked Infra for an opinion on whether it is worth switching. Pro switching - Everything would be in house; no dependence on donations; Con - If it ain't broke, don't fix it; Sonic.net is helpfully willing to donate the service to us and they aren't about to go away. The ticket I created with Infra: https://issues.apache.org/jira/browse/INFRA-12418 Sidney
Re: Secondary DNS Changes - update needed on your end.
Axb wrote on 13/08/16 12:26 AM: > Sidney, > > As we don't have the need of donated DNS services anymore I suggest we > move spamassassin.org to Apache infra (and change @registrar) > > Does that make sense? > > Axb > Good point. I don't know the historical background of the current configuration, but after so many years it is probably a good idea to check with infra to see if it makes more sense to bring it in house and not rely on donated services. I'll follow up with them. Sidney
Re: Secondary DNS Changes - update needed on your end.
[This email is Bcc'd to earlier recipients as I am now moving the discussion to the public dev@ mailing list] This thread got started on the private SpamAssassin PMC mailing list when we were notified there of a required infrastucture update for our DNS. In keeping with Apache Software Foundation policy that all project business that does not require confidentiality be on a public mailing list, I am posting this here on dev@. On looking into it I have found that committers have the ability to do the required update to our DNS configuration by following the procedures in the README file https://svn.apache.org/repos/asf/spamassassin/dns/README I'll take care of it, and will also update the information that is on https://wiki.apache.org/spamassassin/InfraNotes to include a section on maintaining our DNS configuration. Sidney > Dear Sonic Customer, You are receiving this notice because you have been > using Sonic's Secondary DN > > Dear Sonic Customer, > > You are receiving this notice because you have been using Sonic's Secondary > DNS Service for your domain or domains: > > spamassassin.org > > Sonic is in the process of updating our DNS server infrastructure. To > continue using Sonic Secondary DNS Service, you will need to update your > DNS master server as follows: > > * Remove references to the retired secondary master server at 64.142.8.20 > and notify server at 64.142.100.92 > * Add the new secondary master and notify server IP address with the new > address 184.23.168.134 > > You will need to complete your changes by no later than midnight, August 15, > 2016. > > For more information including an example BIND zone configuration, please > view the following page: > Sonic Wiki: Secondary DNS Service > > Please do not hesitate to contact us with any questions by replying to this > email or by telephone at (707) 237-6211 during normal business hours. > > Regards, > Sonic Operations Department >
Re: Secondary DNS Changes - update needed on your end.
[This email is Bcc'd to earlier recipients as I am now moving the discussion to the public dev@ mailing list] This thread got started on the private SpamAssassin PMC mailing list when we were notified there of a required infrastucture update for our DNS. In keeping with Apache Software Foundation policy that all project business that does not require confidentiality be on a public mailing list, I am posting this here on dev@. On looking into it I have found that committers have the ability to do the required update to our DNS configuration by following the procedures in the README file https://svn.apache.org/repos/asf/spamassassin/dns/README I'll take care of it, and will also update the information that is on https://wiki.apache.org/spamassassin/InfraNotes to include a section on maintaining our DNS configuration. Sidney > Dear Sonic Customer, You are receiving this notice because you have been > using Sonic's Secondary DN > > Dear Sonic Customer, > > You are receiving this notice because you have been using Sonic's Secondary > DNS Service for your domain or domains: > > spamassassin.org > > Sonic is in the process of updating our DNS server infrastructure. To > continue using Sonic Secondary DNS Service, you will need to update your > DNS master server as follows: > > * Remove references to the retired secondary master server at 64.142.8.20 > and notify server at 64.142.100.92 > * Add the new secondary master and notify server IP address with the new > address 184.23.168.134 > > You will need to complete your changes by no later than midnight, August 15, > 2016. > > For more information including an example BIND zone configuration, please > view the following page: > Sonic Wiki: Secondary DNS Service > > Please do not hesitate to contact us with any questions by replying to this > email or by telephone at (707) 237-6211 during normal business hours. > > Regards, > Sonic Operations Department >
Re: New Apache SpamAssassin Project Chair
John Hardin wrote on 16/06/16 11:50 PM: > Anyone who wants to contribute to masscheck should drop Sidney a fresh > note now, I don't think we should rely on him being forwarded that > information from KAM. > Oh, definitely send a fresh note, as usual to private@ as described on https://wiki.apache.org/spamassassin/NightlyMassCheck I'm just coming up to speed on how to set up the accounts, so it may take a while yet before I get to them. I saw the requests coming through but assumed that they were being processed. Thanks, Sidney
New Apache SpamAssassin Project Chair
Hi everyone, There has been a change in the role of Chair for the Apache SpamAssassin Project Management Committee. Kevin A. McGrail cannot at this time continue the great work he has been doing as Chair for the past four years. We wish him the best and stand ready to welcome him back if and when that becomes possible. The Apache SpamAssassin PMC nominated me to serve as the new project chair. The Board of Directors for the Apache Software Foundation voted at their June meeting to accept the nomination and appoint me to the position. My priorities at the moment are for us to get a 3.4.2 release as soon as possible, and to make sure that the infrastructure for mass-check and rule updates has all the capacity and redundancy it needs to ensure that it can continue to run smoothly. Anyone who has any other suggestions about what needs doing, please speak up. Of course as always, patches welcome. Regards, Sidney Markowitz
