`rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)

[Volkan Yazıcı]

INFRA has dropped the `rel`-prefixed tag requirement. (See this
`users@infra` thread
.)

Yet I get the team's sentiment on provenance and I agree with it. Yet the
RC (release candidates) case is a bit muddy. I propose the following: For
voting purposes, only share the commit ID, and only create a `rel/x.y.z`
tag if the vote passes.

This captures two conditions stated so far:
1. Not polluting the tag-space
2. Immutable references to release commits

Unless you have objections, I will implement this for `l-l-tools` and
`l-l-transform`.

-- Forwarded message -
From: Ralph Goers 
Date: Fri, May 5, 2023 at 6:17 AM
Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
To: 


OK, thanks for the clarification. I do have a strong opinion. Infra made it
clear that rel/ is for tagging releases. Release candidates are NOT
releases. Furthermore, if you find a problem before starting a vote it is
very easy to just delete a non-rel/ tag and rerun the candidate. Once the
vote starts the tag should not be deleted but it is otherwise very
confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
or rc4. What happened to the missing candidates? It just creates needless
permanent tags in the repo and gets annoying for users who are looking for
just the “real” release tags.

Release candidates should ALWAYS use a tag that is completely separate from
the release tags for the above reasons.  To be honest, I might consider
voting -1 on future releases that don’t do that.

Ralph

> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz 
wrote:
>
> Hi Ralph,
>
> On Thu, 4 May 2023 at 22:35, Ralph Goers 
wrote:
>>
>> That makes me question what is in the actual release.  Tags named “rel/“
are immutable so you can’t have added anything to that after the first rc.
>
> It took me a while to get the automatic release scripts going. So there
was:
>
> * rel/0.1.0.rc1 (with a dot): first attempt with
> `maven-release-plugin`, which pushed the tag,
> * rel/0.1.0-rc2: second release candidate, first deployed by Github
> Actions, the tag is mine,
> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
> deployed by Github Actions, the tag was also pushed by GA. In an
> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>
> Sorry for the confusion. I guess the tagging policy will be a hot
> topic of the next meeting. Personally I don't have a strong opinion in
> this regard, I just copied what `l-l-tools` does.
>
> Piotr

Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0

[Ralph Goers]

+1
(With minor reservations)

It built (but took 15 minutes)
The artifact is properly signed.
Verifying the hash still doesn’t work properly

shasum -a 512 --check apache-log4j-transform-0.1.0-src.zip.sha512 
shasum: apache-log4j-transform-0.1.0-src.zip.sha512: no properly formatted SHA 
checksum lines found
This is because the sha512 file only contains the hash and no longer has the 
file name. I suggest looking at the log4j 2.x distribution pom.

I built and ran my test project and it ran fine. However, the first time I ran 
my project build it failed as below. I ran it several more times and it worked 
the second time, failed the same way the third time and then worked the few 
times I ran it again after that.

[ERROR] Failed to execute goal 
org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes 
(default) on project customer-engagement-service: Execution default of goal 
org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes 
failed: An API incompatibility was encountered while executing 
org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0:process-classes: 
java.lang.ClassFormatError: Truncated class file
[ERROR] -
[ERROR] realm =
plugin>org.apache.logging.log4j:log4j-transform-maven-plugin:0.1.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/Users/rgoers/.m2/repository/org/apache/logging/log4j/log4j-transform-maven-plugin/0.1.0/log4j-transform-maven-plugin-0.1.0.jar
[ERROR] urls[1] = 
file:/Users/rgoers/.m2/repository/org/apache/logging/log4j/log4j-weaver/0.1.0/log4j-weaver-0.1.0.jar
[ERROR] urls[2] = 
file:/Users/rgoers/.m2/repository/org/ow2/asm/asm/9.5/asm-9.5.jar
[ERROR] urls[3] = 
file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-commons/9.5/asm-commons-9.5.jar
[ERROR] urls[4] = 
file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-tree/9.5/asm-tree-9.5.jar
[ERROR] urls[5] = 
file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-util/9.5/asm-util-9.5.jar
[ERROR] urls[6] = 
file:/Users/rgoers/.m2/repository/org/ow2/asm/asm-analysis/9.5/asm-analysis-9.5.jar
[ERROR] urls[7] = 
file:/Users/rgoers/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
[ERROR] urls[8] = 
file:/Users/rgoers/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.1/plexus-utils-3.5.1.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
[ERROR] 
[ERROR] -

Ralph

> On May 2, 2023, at 12:08 PM, Piotr P. Karwasz  wrote:
> 
> The Apache Log4j Transformation Tools 0.1.0 release is now available for 
> voting.
> 
> This is the first release and it contains two modules:
> 
> * [LOG4J2-3638]: Adds a bytecode transformation tool to provide
> location information without reflection.
> * [LOG4J2-673]: Adds a resource transformer for the Maven Shade Plugin
> to merge `Log4j2Plugins.dat` plugin caches. Thanks to Eduard
> Gizatullin.
> 
> Changes between RC2 and RC3:
> 
> * The `log4j-transform-maven-plugin` has a `includes/excludes` setting
> now (useful for benchmark testing),
> * There is a `log4j-transform-perf` module (not in the main reactor
> for a chicken and egg problem),
> * The release was fully automated (hence the 0.1.0-rc1 tag instead of
> 0.1.0-rc3 tag due to some differences between my bash and Github),
> * The source archive does not have Git and Github-related stuff (thanks Gary).
> 
> Source repository: https://github.com/apache/logging-log4j-transform
> Tag: rel/0.1.0-rc1
> Commit: b49a898f74e1ceaa8cd883f211c0a9c30ef8f5c1
> Artifacts: 
> https://dist.apache.org/repos/dist/dev/logging/log4j-transform/0.1.0
> Nexus repository:
> https://repository.apache.org/content/repositories/orgapachelogging-1106
> CI job run: 
> https://github.com/apache/logging-log4j-transform/actions/runs/4864531191
> Signing key: 
> https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0&fingerprint=on&op=index
> Website: https://logging.staged.apache.org/log4j/2.x/log4j-transform
> 
> Please download, test, and cast your votes on the Log4j developers list.
> 
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
> 
> The vote will remain open for 72 hours 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.
> 
> Countdown: 
> https://www.timeanddate.com/countdown/launch?iso=20230505T2115&p0=4162&msg=Log4j+Transformation+Tools+0.1.0&font=cursive

Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)

[Matt Sicker]

This sounds reasonable, though I wonder how it works with the 
maven-release-plugin? I thought that automatically created tags.

> On May 5, 2023, at 3:47 AM, Volkan Yazıcı  wrote:
> 
> INFRA has dropped the `rel`-prefixed tag requirement. (See this
> `users@infra` thread
> .)
> 
> Yet I get the team's sentiment on provenance and I agree with it. Yet the
> RC (release candidates) case is a bit muddy. I propose the following: For
> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
> tag if the vote passes.
> 
> This captures two conditions stated so far:
> 1. Not polluting the tag-space
> 2. Immutable references to release commits
> 
> Unless you have objections, I will implement this for `l-l-tools` and
> `l-l-transform`.
> 
> -- Forwarded message -
> From: Ralph Goers 
> Date: Fri, May 5, 2023 at 6:17 AM
> Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
> To: 
> 
> 
> OK, thanks for the clarification. I do have a strong opinion. Infra made it
> clear that rel/ is for tagging releases. Release candidates are NOT
> releases. Furthermore, if you find a problem before starting a vote it is
> very easy to just delete a non-rel/ tag and rerun the candidate. Once the
> vote starts the tag should not be deleted but it is otherwise very
> confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
> or rc4. What happened to the missing candidates? It just creates needless
> permanent tags in the repo and gets annoying for users who are looking for
> just the “real” release tags.
> 
> Release candidates should ALWAYS use a tag that is completely separate from
> the release tags for the above reasons.  To be honest, I might consider
> voting -1 on future releases that don’t do that.
> 
> Ralph
> 
>> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz 
> wrote:
>> 
>> Hi Ralph,
>> 
>> On Thu, 4 May 2023 at 22:35, Ralph Goers 
> wrote:
>>> 
>>> That makes me question what is in the actual release.  Tags named “rel/“
> are immutable so you can’t have added anything to that after the first rc.
>> 
>> It took me a while to get the automatic release scripts going. So there
> was:
>> 
>> * rel/0.1.0.rc1 (with a dot): first attempt with
>> `maven-release-plugin`, which pushed the tag,
>> * rel/0.1.0-rc2: second release candidate, first deployed by Github
>> Actions, the tag is mine,
>> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
>> deployed by Github Actions, the tag was also pushed by GA. In an
>> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>> 
>> Sorry for the confusion. I guess the tagging policy will be a hot
>> topic of the next meeting. Personally I don't have a strong opinion in
>> this regard, I just copied what `l-l-tools` does.
>> 
>> Piotr

Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)

[Ralph Goers]

Yes, the maven release plugin creates tags (unless you configure it to create a 
branch instead). But Volkan is not using the release plugin. 

I am not really sure what the issue is with creating a tag named 
log4j-tools-1.1.0-rc1. These tags can be deleted later if you don’t want them 
once the rel tag is created.

Yes, one can work from the commit id but that is a bit cumbersome.

Ralph

> On May 5, 2023, at 9:11 AM, Matt Sicker  wrote:
> 
> This sounds reasonable, though I wonder how it works with the 
> maven-release-plugin? I thought that automatically created tags.
> 
>> On May 5, 2023, at 3:47 AM, Volkan Yazıcı  wrote:
>> 
>> INFRA has dropped the `rel`-prefixed tag requirement. (See this
>> `users@infra` thread
>> .)
>> 
>> Yet I get the team's sentiment on provenance and I agree with it. Yet the
>> RC (release candidates) case is a bit muddy. I propose the following: For
>> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
>> tag if the vote passes.
>> 
>> This captures two conditions stated so far:
>> 1. Not polluting the tag-space
>> 2. Immutable references to release commits
>> 
>> Unless you have objections, I will implement this for `l-l-tools` and
>> `l-l-transform`.
>> 
>> -- Forwarded message -
>> From: Ralph Goers 
>> Date: Fri, May 5, 2023 at 6:17 AM
>> Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0
>> To: 
>> 
>> 
>> OK, thanks for the clarification. I do have a strong opinion. Infra made it
>> clear that rel/ is for tagging releases. Release candidates are NOT
>> releases. Furthermore, if you find a problem before starting a vote it is
>> very easy to just delete a non-rel/ tag and rerun the candidate. Once the
>> vote starts the tag should not be deleted but it is otherwise very
>> confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3
>> or rc4. What happened to the missing candidates? It just creates needless
>> permanent tags in the repo and gets annoying for users who are looking for
>> just the “real” release tags.
>> 
>> Release candidates should ALWAYS use a tag that is completely separate from
>> the release tags for the above reasons.  To be honest, I might consider
>> voting -1 on future releases that don’t do that.
>> 
>> Ralph
>> 
>>> On May 4, 2023, at 1:48 PM, Piotr P. Karwasz 
>> wrote:
>>> 
>>> Hi Ralph,
>>> 
>>> On Thu, 4 May 2023 at 22:35, Ralph Goers 
>> wrote:
 
 That makes me question what is in the actual release.  Tags named “rel/“
>> are immutable so you can’t have added anything to that after the first rc.
>>> 
>>> It took me a while to get the automatic release scripts going. So there
>> was:
>>> 
>>> * rel/0.1.0.rc1 (with a dot): first attempt with
>>> `maven-release-plugin`, which pushed the tag,
>>> * rel/0.1.0-rc2: second release candidate, first deployed by Github
>>> Actions, the tag is mine,
>>> * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate,
>>> deployed by Github Actions, the tag was also pushed by GA. In an
>>> effort to order things up I manually pushed `rel/0.1.0-rc3`.
>>> 
>>> Sorry for the confusion. I guess the tagging policy will be a hot
>>> topic of the next meeting. Personally I don't have a strong opinion in
>>> this regard, I just copied what `l-l-tools` does.
>>> 
>>> Piotr
> 

Re: [VOTE] Release log4cxx 1.1.0-RC2

[Piotr P. Karwasz]

Hi Robert,

On Thu, 4 May 2023 at 15:57, Thorsten Schöning  wrote:
>
> Guten Tag Robert Middleton,
> am Mittwoch, 3. Mai 2023 um 12:38 schrieben Sie:
>
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...

I successfully compiled and ran tests with GCC 10.2.1 on Debian.
Hashes and signatures also match.

+1

Piotr

Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0

[Piotr P. Karwasz]

On Fri, 5 May 2023 at 18:09, Ralph Goers  wrote:
>
> +1
> (With minor reservations)

And this is my +1 (also with minor reservations).

All Maven artifacts are reproducible,

The source archive has been also attached to `log4j-transform-bom`. It
can have reproducibility problems if computed on a non-entirely clean
git repo: empty directories are not detected as changes by git, but
end up in the source archive.

Anyway: the RC3 vote passes with binding votes from Ralph, Volkan and myself.

I'll continue the release process.

Piotr

Re: `rel`-prefixed tags (Was: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0)

[Piotr P. Karwasz]

Hi Volkan,

On Fri, 5 May 2023 at 10:47, Volkan Yazıcı  wrote:
> Yet I get the team's sentiment on provenance and I agree with it. Yet the
> RC (release candidates) case is a bit muddy. I propose the following: For
> voting purposes, only share the commit ID, and only create a `rel/x.y.z`
> tag if the vote passes.
>
> This captures two conditions stated so far:
> 1. Not polluting the tag-space
> 2. Immutable references to release commits
>
> Unless you have objections, I will implement this for `l-l-tools` and
> `l-l-transform`.

+1

Some remarks on my experience with the automatic release process:

 * release deployment should **not** be triggered by a push. I should
be a `workflow_dispatch` triggered manually with parameters (e.g. the
release number). I almost triggered RC4 when merging `release/0.1.0`
with `main`,
 * we could reuse some Github Actions like
https://github.com/apache/maven-gh-actions-shared/tree/v3
 * the CI build should use all bells and whistles. E.g. I will disable
integration tests in the default build profile on `l-l-transform`,
because it slows down builds considerably. But I want the CI to run
them.
 * a `verify-release` profile would be useful. There is no reason to
verify build reproducibility manually. An `artifact:compare` execution
should be able to do it.

Piotr

Re: [VOTE] Release log4cxx 1.1.0-RC2

[Robert Middleton]

Adding my +1.

With that, the vote officially passes with the +3 votes from me,
Piotr, and Volkan, with Thorsten and Steven adding their +1 as well.

I will proceed with the release.

-Robert Middleton

On Fri, May 5, 2023 at 2:04 PM Piotr P. Karwasz  wrote:
>
> Hi Robert,
>
> On Thu, 4 May 2023 at 15:57, Thorsten Schöning  wrote:
> >
> > Guten Tag Robert Middleton,
> > am Mittwoch, 3. Mai 2023 um 12:38 schrieben Sie:
> >
> > > Please download, test, and cast your votes on the log4j developers list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
>
> I successfully compiled and ran tests with GCC 10.2.1 on Debian.
> Hashes and signatures also match.
>
> +1
>
> Piotr