Created LEGAL-647[1]. Note that INFRA recommends[2] and explains[3] this technique too.
[1] https://issues.apache.org/jira/browse/LEGAL-647 [2] https://infra.apache.org/release-publishing.html#signing [3] https://infra.apache.org/release-signing.html#automated-release-signing On Tue, Jul 4, 2023 at 9:07 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > Closed the Nexus repo. > > Will create a JIRA ticket for the Legal to update the release policy. > > On Tue, Jul 4, 2023 at 8:20 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > I have verified the artifact in the distribution directory. It looks fine. > > > > I am hesitant to vote on this though as you have not closed the release in > > the Nexus repo at repository.apache.org, which means you can still add > > stuff to that. Once you close that I will vote on this. > > > > I am still concerned about the lack of documentation around using a signing > > key by "ASF Logging Services RM <priv...@logging.apache.org>”. I do not > > want to continue to be questioned about this and we need some sort of > > documentation indicating that doing this is OK - such as getting > > https://www.apache.org/legal/release-policy.html#release-signing changed as > > it currently says "All release artifacts within the directory MUST be > > signed by a committer, preferably a PMC member” and/or > > https://infra.apache.org/release-publishing.html which does say "Infra > > strongly recommends that projects set up automated infrastructure to sign > > the files to simplify the work” which seems to be on the right track but > > isn’t really as clear as it needs to be. For example, Log4j uses an > > automated infrastructure to currently sign releases. The RM’s machine just > > has to be configured for it. It isn’t at all clear that they are approving > > not having the key be owned by an individual. > > > > Since the main release policy page is owned by legal I would suggest you > > create a Jira issue to get the page updated. > > > > Ralph > > > > > On Jul 3, 2023, at 2:29 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > > > This is a vote to release the Apache Log4j Tools 0.4.0. > > > > > > Source repository: https://github.com/apache/logging-log4j-tools > > > Commit: 15d888fe488660b0bb5d3fc3e95c9915f277fbee > > > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j > > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > > > Please download, test, and cast your votes on the Log4j developers list. > > > > > > [ ] +1, release the artifacts > > > [ ] -1, don't release, because... > > > > > > This vote is open for 72 hours and will pass unless getting a net > > > negative vote count. All votes are welcome and we encourage everyone to > > > test the release, but only the Logging Services PMC votes are officially > > > counted. At least 3 +1 votes and more positive than negative votes are > > > required. > > > > > > # Release Notes > > > > > > This minor release contains small enhancements. > > > Most importantly, this marks the first release where the project uses > > > itself to generate release notes! > > > > > > ## Changes > > > > > > ### Added > > > > > > * Add `versionPattern` (i.e., the regular expression pattern for > > > parsing versions) parameter to the Maven `release` goal (#63) > > > > > > ### Changed > > > > > > * Change the default value of `outputDirectory` to > > > `${project.build.directory}/generated-sources/site/changelog` for the > > > Maven `export` goal > > > * Migrate from `CHANGELOG.adoc` to using `log4j-changelog-maven-plugin` > > > > > > ### Fixed > > > > > > * Improve Maven `release` goal to accommodate repetitive invocations > >
