Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

Right, it is a copy-paste mistake from the release email template. (Though
this gave me the idea of generating this email from the template in CI
during the release!)

This VOTE is for the 0.4.0 release of Apache Log4j Tools.

On Mon, Jul 3, 2023 at 12:01 AM Gary Gregory  wrote:

> Is it 0.4.0 or 7.8.0? ;-)
>
> Gary
>
> On Sun, Jul 2, 2023, 14:54 Volkan Yazıcı  wrote:
>
> > This is a lazy vote to release the Apache Log4j Tools 7.8.0.
> >
> > This minor release contains small enhancements. Most importantly, this
> > marks the first release where the project uses itself to generate
> > release notes!
> >
> > Source repository: https://github.com/apache/logging-log4j-tools
> > Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
> > Artifacts: 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.
> >
> > ## 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
> >
>

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

Of course the artifacts are available in the Maven repository under their
usual folder:
https://repository.apache.org/content/repositories/orgapachelogging-1110

I simplified the VOTE email to *only* include details necessary for an
ASF-compliant release. Note that Maven is a convenience, not an officially
supported distribution medium.

On Mon, Jul 3, 2023 at 6:36 AM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Sun, 2 Jul 2023 at 20:54, Volkan Yazıcı  wrote:
> > Source repository: https://github.com/apache/logging-log4j-tools
> > Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
> > Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j
> > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Where is the Maven repo? Are these artifacts only available as ZIP
> download?
>
> Piotr
>

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Vladimir Sitnikov]

-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

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

Hey Vladimir!

Thanks for the review!
I will address remarks inline.

On Mon, Jul 3, 2023 at 1:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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?
>

You are right.
It was a mistake (code typo) by my side.
I will cancel the vote and start a new one.


> > 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.
>

I did not omit the link to "the distribution", it is there in the VOTE
email: https://dist.apache.org/repos/dist/dev/logging/log4j The version
number matches the one cited in the VOTE email title (yup, there was a typo
in the email body) and the source code referenced by the commit ID shared.

>Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Could you please clarify who owns and controls the key?
>

See INFRA-23996 for details. There you can find reference to the approval
of Mark J. Cox, the VP of Security, on the employed technique.


> >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?
>

Apache Log4j Tools is an internal project used by Apache Logging Services
to support Apache Log4j infrastructure and it is not intended for public
consumption. This is made clear in its documentation too. If you still
think this is an issue, let me know, we can discuss this further in
`members@`.

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

I am cancelling this VOTE since

1. Sources are missing in the distribution
2. Email body cites the wrong version number

I will promptly create a new release followed by a  new VOTE thread.

On Sun, Jul 2, 2023 at 8:54 PM Volkan Yazıcı  wrote:

> This is a lazy vote to release the Apache Log4j Tools 7.8.0.
>
> This minor release contains small enhancements. Most importantly, this
> marks the first release where the project uses itself to generate
> release notes!
>
> Source repository: https://github.com/apache/logging-log4j-tools
> Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
> Artifacts: 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.
>
> ## 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
>

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Gary Gregory]

Hi Volkan

Have a look at what we do in Commons where I generate the vote email's text
to a file for the RM to review. For example:

git clone https://ggreg...@gitbox.apache.org/repos/asf/commons-io.git && cd
commons-io
mvn -Dcommons.nexus.repo.id=$commons_nexus_repo_id
org.apache.commons:commons-release-plugin:1.8.1:vote-txt
open target/VOTE.txt

Gary

On Mon, Jul 3, 2023, 06:05 Volkan Yazıcı  wrote:

> Right, it is a copy-paste mistake from the release email template. (Though
> this gave me the idea of generating this email from the template in CI
> during the release!)
>
> This VOTE is for the 0.4.0 release of Apache Log4j Tools.
>
> On Mon, Jul 3, 2023 at 12:01 AM Gary Gregory 
> wrote:
>
> > Is it 0.4.0 or 7.8.0? ;-)
> >
> > Gary
> >
> > On Sun, Jul 2, 2023, 14:54 Volkan Yazıcı  wrote:
> >
> > > This is a lazy vote to release the Apache Log4j Tools 7.8.0.
> > >
> > > This minor release contains small enhancements. Most importantly, this
> > > marks the first release where the project uses itself to generate
> > > release notes!
> > >
> > > Source repository: https://github.com/apache/logging-log4j-tools
> > > Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
> > > Artifacts: 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.
> > >
> > > ## 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
> > >
> >
>

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Gary Gregory]

Well, don't use my ID in your clone ;-)

Gary

On Mon, Jul 3, 2023 at 9:16 AM Gary Gregory  wrote:
>
> Hi Volkan
>
> Have a look at what we do in Commons where I generate the vote email's text 
> to a file for the RM to review. For example:
>
> git clone https://ggreg...@gitbox.apache.org/repos/asf/commons-io.git && cd 
> commons-io
> mvn -Dcommons.nexus.repo.id=$commons_nexus_repo_id 
> org.apache.commons:commons-release-plugin:1.8.1:vote-txt
> open target/VOTE.txt
>
> Gary
>
> On Mon, Jul 3, 2023, 06:05 Volkan Yazıcı  wrote:
>>
>> Right, it is a copy-paste mistake from the release email template. (Though
>> this gave me the idea of generating this email from the template in CI
>> during the release!)
>>
>> This VOTE is for the 0.4.0 release of Apache Log4j Tools.
>>
>> On Mon, Jul 3, 2023 at 12:01 AM Gary Gregory  wrote:
>>
>> > Is it 0.4.0 or 7.8.0? ;-)
>> >
>> > Gary
>> >
>> > On Sun, Jul 2, 2023, 14:54 Volkan Yazıcı  wrote:
>> >
>> > > This is a lazy vote to release the Apache Log4j Tools 7.8.0.
>> > >
>> > > This minor release contains small enhancements. Most importantly, this
>> > > marks the first release where the project uses itself to generate
>> > > release notes!
>> > >
>> > > Source repository: https://github.com/apache/logging-log4j-tools
>> > > Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
>> > > Artifacts: 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.
>> > >
>> > > ## 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
>> > >
>> >

Re: [VOTE][LAZY] Release Apache Log4j Tools 0.4.0

[Ralph Goers]

-1 (binding)

a) the distribution directory contains only binaries. An ASF release must have 
a source distribution.
b) I believe you worked with INFRA to get permission to use the automation 
signing key, but without a link to that and instructions that pointedly require 
keys owned by individuals this is going to create problems.

-1 on this being a lazy vote. I have every intention of using the changelog 
plugin in Flume once I am comfortable that it is ready for prime time without 
hand-holding.

Ralph



> On Jul 2, 2023, at 11:54 AM, Volkan Yazıcı  wrote:
> 
> This is a lazy vote to release the Apache Log4j Tools 7.8.0.
> 
> This minor release contains small enhancements. Most importantly, this
> marks the first release where the project uses itself to generate
> release notes!
> 
> Source repository: https://github.com/apache/logging-log4j-tools
> Commit: b4d75a1270d4eeaa99ffd1425332572ed3bd3e73
> Artifacts: 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.
> 
> ## 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

Re: Creating "the distribution" via BeanShell

[Matt Sicker]

Reply is inline below:

> On Jul 2, 2023, at 2:57 PM, Volkan Yazıcı  wrote:
> 
> *Abstract:* `log4j-tools` 0.4.0 release contains a `beanshell-maven-plugin`
> block that created the distribution ZIP in a way that addresses all past
> concerns of PMC, it is reusable by other projects without any changes,
> integrates with `log4j-changelog-maven-plugin`, uses JGit to collect
> sources, and composed of 79 lines of BeanShell script
> 
> .
> 
> It is no secret that I have been spending quite some time on _perfecting_
> the `logging-log4j-tools` Maven and release infrastructure. I will soon be
> breaking the `logging-log4j2` repository into multiple repositories, and
> there I want to take the `l-l-tools` as reference. Hence, my push for the
> simplest and reusable Maven+release infra there.

This sounds great so far!

> In `l-l-tools` 0.4.0 release, I have done something different, addressing
> all these concerns and delivering even more! `l-l-tools` 0.4.0 release
> contains a `beanshell-maven-plugin` block creating the distribution ZIP
> such that
> 
>   - The entire logic is composed of 79 lines of BeanShell – including
>   import statements, comments, and empty lines!
>   - `RELEASE-NOTES.md` is generated from `src/changelog` and included in
>   the distribution ZIP.
>   - `git ls-files` output is obtained using JGit (in BeanShell) and
>   compressed in a reproducible & platform-independent way.
>   - JARs to be added to the distribution ZIP are matched using regex.

A Java build using Java? Imagine that! I’ve only seen a very small handful of 
Java projects that use actual Java code in their build and not an XML thesis. I 
like this approach for handling this part of the build, especially since it’s 
not Groovy+Gradle where things get hard to follow.

> *The distribution must contain binaries too*
> 
> I disagree with this sentiment. Yet there are multiple PMC members
> practicing this "copy-pasting downloaded JARs to the server" tradition.
> Hence, the new release procedure bundles  binaries too.

Making a source release to downloads.a.o along with publishing all our usual 
jar files (binaries and sources) covers our main channels here. When Log4j2 was 
mainly the API and Core modules, then it seemed more reasonable that people 
would be downloading the jar files without a dependency manager, but with the 
increased modularity and continued industry convergence on using dependency 
managers, I think this approach would be sufficient.

> *What is next?*
> 
> Distribute this logic in `logging-parent` POM and reuse it in
> `logging-log4j-transform` as a PoC.

I’d love to reuse this in the Kotlin API, too. The easier this all is to use, 
the easier it’ll be to maintain multiple repositories.

Re: Creating "the distribution" via BeanShell

[Ralph Goers]

I replied to this thread from lists.a.o since I didn’t get Volkan’s email but I 
have not seen the moderation request yet.  I have a few comments to this.

> On Jul 3, 2023, at 8:36 AM, Matt Sicker  wrote:
> 
> Reply is inline below:
> 
>> *The distribution must contain binaries too*
>> 
>> I disagree with this sentiment. Yet there are multiple PMC members
>> practicing this "copy-pasting downloaded JARs to the server" tradition.
>> Hence, the new release procedure bundles  binaries too.
> 
> Making a source release to downloads.a.o along with publishing all our usual 
> jar files (binaries and sources) covers our main channels here. When Log4j2 
> was mainly the API and Core modules, then it seemed more reasonable that 
> people would be downloading the jar files without a dependency manager, but 
> with the increased modularity and continued industry convergence on using 
> dependency managers, I think this approach would be sufficient.

People still download from dist.a.o. I have no idea why but I know they do as I 
have gotten emails regarding the asc file not containing the data in the 
“correct” format.

> 
>> *What is next?*
>> 
>> Distribute this logic in `logging-parent` POM and reuse it in
>> `logging-log4j-transform` as a PoC.
> 
> I’d love to reuse this in the Kotlin API, too. The easier this all is to use, 
> the easier it’ll be to maintain multiple repositories.

Hence my insistence that this be a true Maven plugin, not a script.

Ralph

RE: Creating "the distribution" via BeanShell

[Ralph Goers]

Trying this again as I have not seen my reply show up for moderation.

On 2023/07/02 19:57:08 Volkan Yazıcı wrote:
> *Abstract:* `log4j-tools` 0.4.0 release contains a `beanshell-maven-plugin`
> block that created the distribution ZIP in a way that addresses all past
> concerns of PMC, it is reusable by other projects without any changes,
> integrates with `log4j-changelog-maven-plugin`, uses JGit to collect
> sources, and composed of 79 lines of BeanShell script
> 

While I have no issue with the logic of what is being done I do object to using 
BeanShell to do it. This smacks of going back to Ant/Make and “rolling your 
own”. It is also way too tempting for people to just go and modify the script 
since it is right there in the pom.

It also looks like the Script is basically Java code, so converting that to a 
Maven Plugin should be easy.

> .
> 
> It is no secret that I have been spending quite some time on _perfecting_
> the `logging-log4j-tools` Maven and release infrastructure. I will soon be
> breaking the `logging-log4j2` repository into multiple repositories, and
> there I want to take the `l-l-tools` as reference. Hence, my push for the
> simplest and reusable Maven+release infra there.
> 
> `l-l-tools` has the simplest ASF-compliant releasing procedure
> 
> out there in the wild. Though my use of `git ls-files | sort | zip` to
> generate "the distribution" ZIP has been a subject of certain discussions.
> I share an exhaustive list of all the complaints so far:
> 
>1. `git ls-files | sort | zip` is not reproducible!
>2. `git ls-files | sort | zip` cannot be executed on Windows!
>3. Why do we package `.github`, `.asf.yaml`, etc. files that are not
>relevant for the release in the distribution?
>4. The distribution must contain binaries, not only sources, since there
>are people still living in 1998, downloading JARs from the ASF website, and
>copy-pasting them into their servers.
>5. The distribution must contain the release notes, because... we have
>been doing this for more than decade while releasing Log4j.
>6. Why don't we simply use `maven-assembly-plugin` just like we do in
>Log4j?

I don’t recall seeing any of these complaints, but ok.


> 
> In `l-l-tools` 0.4.0 release, I have done something different, addressing
> all these concerns and delivering even more! `l-l-tools` 0.4.0 release
> contains a `beanshell-maven-plugin` block creating the distribution ZIP
> such that
> 
>- The entire logic is composed of 79 lines of BeanShell – including
>import statements, comments, and empty lines!
>- `RELEASE-NOTES.md` is generated from `src/changelog` and included in
>the distribution ZIP.
>- `git ls-files` output is obtained using JGit (in BeanShell) and
>compressed in a reproducible & platform-independent way.
>- JARs to be added to the distribution ZIP are matched using regex.

The regex in the script is hard-coded. We also don’t currently include all the 
binaries produced (on purpose). As a Maven Plugin it would be easy to provide 
the configuration to supply/override the regex and to provide artifacts to 
exclude.

Ralph

[VOTE] Release Apache Log4j Tools 0.4.0

[Volkan Yazıcı]

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

[Discuss][VOTE] Release Apache Log4j Tools 0.4.0

[Ralph Goers]

I am confused. We had a vote thread for 0.4.0. Did you close that vote? Maybe I 
just didn’t get that email again.

The commit tag for this vote is not the same as the previous commit tag. So is 
this really rc-2?  I despise having multiple release vote threads for the same 
release number as it is impossible to differentiate them.

Ralph

> On Jul 3, 2023, at 2:29 PM, Volkan Yazıcı  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

Re: [Discuss][VOTE] Release Apache Log4j Tools 0.4.0

[Gary Gregory]

IMO the email subject and text MUST contain the RC number. It's a small
change that makes a huge difference.

Gary


On Mon, Jul 3, 2023, 18:33 Ralph Goers  wrote:

> I am confused. We had a vote thread for 0.4.0. Did you close that vote?
> Maybe I just didn’t get that email again.
>
> The commit tag for this vote is not the same as the previous commit tag.
> So is this really rc-2?  I despise having multiple release vote threads for
> the same release number as it is impossible to differentiate them.
>
> Ralph
>
> > On Jul 3, 2023, at 2:29 PM, Volkan Yazıcı  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
>
>

[More discussion][VOTE] Release Apache Log4j Tools 0.4.0

[Ralph Goers]

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 ”.  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ı  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