-1, don't release, because...
Volkan, I have downloaded the release artifact apache-log4j-tools-0.4.0.zip, and I fail to find the source package there. Would you please advise? See https://www.apache.org/legal/release-policy.html#what-must-every-release-contain >Every ASF release must contain a source package, which must be sufficient for a user to build and >test the release provided they have access to the appropriate platform and tools I performed unzip apache-log4j-tools-0.4.0.zip, and I find two jar files, LICENSE, NOTICE, and RELEASE-NOTES there. The jar files contain binary/bytecode files, and the release contains no signs of a source package. Please, correct me if I am wrong, but it sounds that "0.4.0 release of Apache Log4j Tools" violates "WHAT MUST EVERY ASF RELEASE CONTAIN?" policy. --- > I simplified the VOTE email to *only* include details necessary for an > ASF-compliant release. It is unfair to omit the link to the published binary/bytecode packages. For instance, if the version in maven publication was different from 0.4.0, then it would violate the ASF policy. The ASF policy does impose several MUST requirements on the released binary/bytecode packages, see https://www.apache.org/legal/release-policy.html#compiled-packages >the binary/bytecode package MUST have the same version number as the source release >and MUST only add binary/bytecode files that are the result of compiling that version of >the source code release and its dependencies. --- >Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 Could you please clarify who owns and controls the key? Correct me if I am wrong, however, the ASF release policy requires that the releases MUST be signed by Release Manager: https://www.apache.org/legal/release-policy.html#release-signing At the same time they say: https://www.apache.org/legal/release-policy.html#owned-controlled-hardware >hardware owned and controlled by the committer. That means hardware the committer has physical possession >and control of and exclusively full administrative/superuser access to. That's because only such hardware >is qualified to hold a PGP private key, and the release should be verified on the machine the private key lives on or on a machine as trusted as that It sounds to me that external systems, including GitHub Actions should not be trusted to store signing private keys. In other words, if the only PGP signature comes from a bot running in GitHub Actions, then it looks to me the release deviates from the ASF Release Policy. --- >This is a lazy vote to release Could you please clarify what do you mean by "This is a lazy vote to release"? The only thing coming to my mind is "lazy consensus", however I do not think lazy consensus can be used for release voting. The ASF policy requires that every time a member of PMC votes, they are REQUIRED to download all signed code onto their hardware and verify it: https://www.apache.org/legal/release-policy.html#release-approval Could you please clarify the meaning of "lazy" in both mail text and the subject? Vladimir
