Vladimir earlier questioned the practice of `[LAZY][VOTE]`. After encountering several other ASF projects reaching out to the same practice and yet knowing that it is not clearly defined in the ASF release policy, I have raised the issue first on `d...@community.apache.org` <https://lists.apache.org/thread/5xpp9f6ntxho7pwfcl9gx7l2cf14bww2> and later on `bo...@apache.org` <https://lists.apache.org/thread/k15gco2snsf9dsfkznp6289msn4vroq8>. There I was asked to create LEGAL-654 <https://issues.apache.org/jira/browse/LEGAL-654> and Roman Shaposhnik (V.P., Legal Affairs) stated that *the `**[LAZY]**[VOTE]` practice is legitimate given it is not advertised as a release for public consumption*.
>From this point of view, both `logging-parent` and `log4j-tools` qualify for `[LAZY][VOTE]`, since we clearly indicate that the tooling is intended for internal usage only. Vladimir, if you have further questions and/or objections, I kindly ask you to share them in LEGAL-654. On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > -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 >
