Re: [VOTE] Release Apache Logging Parent 1.10.0
Check. I will fix the Nexus URL, add the `release-verify` profile, and do an RC2 round. On Tue, Sep 5, 2023 at 8:42 AM Piotr P. Karwasz wrote: > > Hi Volkan, > > On Mon, 4 Sept 2023 at 21:33, Volkan Yazıcı wrote: > > Nexus: > > https://repository.apache.org/content/repositories/orgapachelogging-1113 > > Congratulations on the totally automatic release. Unfortunately there > are still some glitches: > * orgapachelogging-1113 does **not** exist, > * orgapachelogging-1153 is "open". > > Could you also add a "release-verify" profile so that running: > > ./mvnw -P release-verify > -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1113 > > verifies that: > 1. builds are reproducible, > 2. signatures match. > > Piotr
Re: [VOTE] Release Apache Logging Parent 1.10.0
Summary: *THE VOTE IS STILL ON* though the Nexus URL should point to https://repository.apache.org/content/repositories/orgapachelogging-1153 instead! I had a talk with Piotr and we decided to proceed with this release and won't issue an RC2. The only correction is to the Nexus URL. (The release instructions clearly state that the Nexus URL needs to be updated, something I forgot to do while cutting the release.) I will share why we decided to not implement the proposed `release-verify` profile in a separate email thread. On Tue, Sep 5, 2023 at 9:36 AM Volkan Yazıcı wrote: > > Check. I will fix the Nexus URL, add the `release-verify` profile, and > do an RC2 round. > > On Tue, Sep 5, 2023 at 8:42 AM Piotr P. Karwasz > wrote: > > > > Hi Volkan, > > > > On Mon, 4 Sept 2023 at 21:33, Volkan Yazıcı wrote: > > > Nexus: > > > https://repository.apache.org/content/repositories/orgapachelogging-1113 > > > > Congratulations on the totally automatic release. Unfortunately there > > are still some glitches: > > * orgapachelogging-1113 does **not** exist, > > * orgapachelogging-1153 is "open". > > > > Could you also add a "release-verify" profile so that running: > > > > ./mvnw -P release-verify > > -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1113 > > > > verifies that: > > 1. builds are reproducible, > > 2. signatures match. > > > > Piotr
Helper Maven profile for build+sig verification
In a recent post, Piotr suggested the following: > Could you also add a "release-verify" profile so that running: > > ./mvnw -P release-verify -Dreference.repo= https://repository.apache.org/content/repositories/orgapachelogging-1113 > > verifies that: > 1. builds are reproducible, > 2. signatures match. I had a talk with him and we decided to not proceed with adding these features: 1. In the case of reproducibility check... The amount of boilerplate we will be adding doesn't justify the convenience that will potentially be provided to the user. That is, `./mvnw clean verify artifact:compare -Dreference.repo=...` vs `./mvnw -P release-verify -Dreference.repo=...` – the win is negligible. 2. The verification will be against the unofficial Nexus artifacts, not the official ASF SVN uploads. 3. The verification will use local+public key stores, not the `KEYS` file. 4. We don't know of a practical way (i.e., without needing to boil oceans) to validate signatures of artifacts at a particular remote URL. There is `pgpverify-maven-plugin`, but it doesn't accept a repo argument. 5. Can we at least determine the Nexus URL during `deploy` so we don't need to manually correct it every time? Not that we know of. Sonatype's `nxrm3-maven-plugin` provides a tagging feature (which indeed influences the URL), though it only works against Nexus 3 and ASF uses Nexus 2.
Re: [VOTE] Release Apache Logging Parent 1.10.0
Hi Volkan, On Tue, 5 Sept 2023 at 11:04, Volkan Yazıcı wrote: > > Summary: *THE VOTE IS STILL ON* though the Nexus URL should point to > https://repository.apache.org/content/repositories/orgapachelogging-1153 > instead! The POM looks good to me and I verified that: ./mvnw clean verify artifact:compare -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1153 succeeds. Hence my +1. Piotr
Re: [VOTE] Release Apache Logging Parent 1.10.0
Lgtm as far as I can tell :) +1 On Tue, Sep 5, 2023, at 11:15, Piotr P. Karwasz wrote: > Hi Volkan, > > On Tue, 5 Sept 2023 at 11:04, Volkan Yazıcı wrote: >> >> Summary: *THE VOTE IS STILL ON* though the Nexus URL should point to >> https://repository.apache.org/content/repositories/orgapachelogging-1153 >> instead! > > The POM looks good to me and I verified that: > > ./mvnw clean verify artifact:compare > -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1153 > > succeeds. Hence my +1. > > Piotr
Re: [VOTE] Release Apache Logging Parent 1.10.0
Something is wrong with the source zip file at https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a zip that contains a zip. Why? It should be a direct reflection of what is in the repository IMO. Also, the links in the vote email should point to https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not https://dist.apache.org/repos/dist/dev/logging such reviewed don't have to dig through folders. Gary On Mon, Sep 4, 2023 at 3:33 PM Volkan Yazıcı wrote: > > This is a vote to release the Apache Logging Parent 1.10.0. > > Source repository: https://github.com/apache/logging-parent > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > Distribution: https://dist.apache.org/repos/dist/dev/logging > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing 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 various improvements that we expect to > relieve the load on `pom.xml` and GitHub Actions workflows of > Maven-based projects we parent. This is of particular importance while > managing and cutting releases from multiple repositories. > See `README.adoc` for the complete list of features and their usage. > > See [this `logging-log4j-tools` GitHub Actions workflow > run](https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > demonstrating a successful release cut using a SNAPSHOT version of > this `logging-parent` release. All preparations (release notes, > distribution ZIP, vote & announcement emails, etc.) are staged to both > Nexus and SVN and waiting the release manager to proceed. As a matter > of fact, this very release of `logging-parent` is cut by the very same > reusables too. > > ## Changes > > ### Added > > * Added `changelog-export` profile to easily export changelogs to Markdown > files > * Added `changelog-release` profile to easily move > `src/changelog/.?.x.x` contents to their associated release directory > * Added `deploy` profile to ease the Maven `deploy` goal > * Added `distribution` profile to easily create a distribution file > containing Git-tracked sources, release notes, binary attachments, > `NOTICE.txt`, etc. > * Documented release instructions (i.e., `RELEASING.md`) > * Added `release` profile to share common release-specific Maven configuration > * Added reusable GitHub Actions workflows to share CI boilerplate for > other repositories > * Switched to using `log4j-changelog-maven-plugin` for managing > changelog and release notes
Re: [VOTE] Release Apache Logging Parent 1.10.0
My comments are inline. On Tue, Sep 5, 2023 at 1:30 PM Gary Gregory wrote: > Something is wrong with the source zip file at > https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a > zip that contains a zip. Why? *The distribution* is a single file containing sources (`src.zip`), binary artifacts[1], and auxiliary support files (release notes, `LICENSE.txt`, `NOTICE.txt`, etc.) I am not able to follow what is wrong with this. [1] In the case of `logging-parent`, there are no binary artifacts. It is just a `pom.xml` and reusable CI workflow YAMLs. > It should be a direct reflection of what > is in the repository IMO. > [By "repository", I assume you mean Nexus.] In the distribution, we provide everything that is available in the repository, plus more. For me the most important detail is the intact sources that one can reproduce the binary artifacts without any changes. Hence, AFAIC, it is a "a direct reflection". Could you give an example of what the distribution misses that is available in the repository? Additionally, Nexus only stores `pom.xml`, though this release of `logging-parent` has a very important addendum: reusable CI workflow YAMLs. And that is what the distribution captures right. Also, the links in the vote email should point to > https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not > https://dist.apache.org/repos/dist/dev/logging such reviewed don't > have to dig through folders. > Check. Will do in the next release.
Re: [VOTE] Release Apache Logging Parent 1.10.0
I haven’t looked yet but as I recall Volkan is merging the source and binary artifacts into a single zip. So I would expect the zip in the zip is the source. Ralph > On Sep 5, 2023, at 4:30 AM, Gary Gregory wrote: > > Something is wrong with the source zip file at > https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a > zip that contains a zip. Why? It should be a direct reflection of what > is in the repository IMO. > > Also, the links in the vote email should point to > https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not > https://dist.apache.org/repos/dist/dev/logging such reviewed don't > have to dig through folders. > > Gary > >> On Mon, Sep 4, 2023 at 3:33 PM Volkan Yazıcı wrote: >> >> This is a vote to release the Apache Logging Parent 1.10.0. >> >> Source repository: https://github.com/apache/logging-parent >> Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c >> Distribution: https://dist.apache.org/repos/dist/dev/logging >> Nexus: >> https://repository.apache.org/content/repositories/orgapachelogging-1113 >> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 >> >> Please download, test, and cast your votes on this mailing 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 various improvements that we expect to >> relieve the load on `pom.xml` and GitHub Actions workflows of >> Maven-based projects we parent. This is of particular importance while >> managing and cutting releases from multiple repositories. >> See `README.adoc` for the complete list of features and their usage. >> >> See [this `logging-log4j-tools` GitHub Actions workflow >> run](https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) >> demonstrating a successful release cut using a SNAPSHOT version of >> this `logging-parent` release. All preparations (release notes, >> distribution ZIP, vote & announcement emails, etc.) are staged to both >> Nexus and SVN and waiting the release manager to proceed. As a matter >> of fact, this very release of `logging-parent` is cut by the very same >> reusables too. >> >> ## Changes >> >> ### Added >> >> * Added `changelog-export` profile to easily export changelogs to Markdown >> files >> * Added `changelog-release` profile to easily move >> `src/changelog/.?.x.x` contents to their associated release directory >> * Added `deploy` profile to ease the Maven `deploy` goal >> * Added `distribution` profile to easily create a distribution file >> containing Git-tracked sources, release notes, binary attachments, >> `NOTICE.txt`, etc. >> * Documented release instructions (i.e., `RELEASING.md`) >> * Added `release` profile to share common release-specific Maven >> configuration >> * Added reusable GitHub Actions workflows to share CI boilerplate for >> other repositories >> * Switched to using `log4j-changelog-maven-plugin` for managing >> changelog and release notes
Re: [VOTE] Release Apache Logging Parent 1.10.0
Surely you must be joking. I should be able to unzip and build, NOT unzip and then scratch my head, look for other files like zips and tars... sigh, this whole dev process is getting WORSE. And we want to spread sources in a buch of repos, bleh. All Apache and FOSS projects I've seen just have a src zip with a snapshot repo minus some files, not some byzantine structure. How is this nested zip mess HELPING users and lowering the bar to entry? Why are all the ".githug" files even in the source zip file? Baffled, Gary On Tue, Sep 5, 2023, 10:51 AM Volkan Yazıcı wrote: > My comments are inline. > > On Tue, Sep 5, 2023 at 1:30 PM Gary Gregory > wrote: > > > Something is wrong with the source zip file at > > https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a > > zip that contains a zip. Why? > > > *The distribution* is a single file containing sources (`src.zip`), binary > artifacts[1], and auxiliary support files (release notes, `LICENSE.txt`, > `NOTICE.txt`, etc.) I am not able to follow what is wrong with this. > > [1] In the case of `logging-parent`, there are no binary artifacts. It is > just a `pom.xml` and reusable CI workflow YAMLs. > > > > It should be a direct reflection of what > > is in the repository IMO. > > > > [By "repository", I assume you mean Nexus.] > > In the distribution, we provide everything that is available in the > repository, plus more. For me the most important detail is the intact > sources that one can reproduce the binary artifacts without any changes. > Hence, AFAIC, it is a "a direct reflection". Could you give an example of > what the distribution misses that is available in the repository? > > Additionally, Nexus only stores `pom.xml`, though this release of > `logging-parent` has a very important addendum: reusable CI workflow YAMLs. > And that is what the distribution captures right. > > Also, the links in the vote email should point to > > https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not > > https://dist.apache.org/repos/dist/dev/logging such reviewed don't > > have to dig through folders. > > > > Check. Will do in the next release. >
Re: [VOTE] Release Apache Logging Parent 1.10.0
A parent pom is just an XML file though? > On Sep 5, 2023, at 11:20 AM, Gary Gregory wrote: > > Surely you must be joking. > > I should be able to unzip and build, NOT unzip and then scratch my head, > look for other files like zips and tars... sigh, this whole dev process is > getting WORSE. And we want to spread sources in a buch of repos, bleh. > > All Apache and FOSS projects I've seen just have a src zip with a snapshot > repo minus some files, not some byzantine structure. > > How is this nested zip mess HELPING users and lowering the bar to entry? > Why are all the ".githug" files even in the source zip file? > > Baffled, > Gary > > > On Tue, Sep 5, 2023, 10:51 AM Volkan Yazıcı wrote: > >> My comments are inline. >> >> On Tue, Sep 5, 2023 at 1:30 PM Gary Gregory >> wrote: >> >>> Something is wrong with the source zip file at >>> https://dist.apache.org/repos/dist/dev/logging/logging-parent/: It's a >>> zip that contains a zip. Why? >> >> >> *The distribution* is a single file containing sources (`src.zip`), binary >> artifacts[1], and auxiliary support files (release notes, `LICENSE.txt`, >> `NOTICE.txt`, etc.) I am not able to follow what is wrong with this. >> >> [1] In the case of `logging-parent`, there are no binary artifacts. It is >> just a `pom.xml` and reusable CI workflow YAMLs. >> >> >>> It should be a direct reflection of what >>> is in the repository IMO. >>> >> >> [By "repository", I assume you mean Nexus.] >> >> In the distribution, we provide everything that is available in the >> repository, plus more. For me the most important detail is the intact >> sources that one can reproduce the binary artifacts without any changes. >> Hence, AFAIC, it is a "a direct reflection". Could you give an example of >> what the distribution misses that is available in the repository? >> >> Additionally, Nexus only stores `pom.xml`, though this release of >> `logging-parent` has a very important addendum: reusable CI workflow YAMLs. >> And that is what the distribution captures right. >> >> Also, the links in the vote email should point to >>> https://dist.apache.org/repos/dist/dev/logging/logging-parent/ not >>> https://dist.apache.org/repos/dist/dev/logging such reviewed don't >>> have to dig through folders. >>> >> >> Check. Will do in the next release. >>
Re: [VOTE] Release Apache Logging Parent 1.10.0
This doesn’t exactly match the versioning scheme for logging-parent which was a simple integer. This version number is considered much lower than the latest release by Maven as a result. > On Sep 4, 2023, at 2:33 PM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Logging Parent 1.10.0. > > Source repository: https://github.com/apache/logging-parent > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > Distribution: https://dist.apache.org/repos/dist/dev/logging > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing 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 various improvements that we expect to > relieve the load on `pom.xml` and GitHub Actions workflows of > Maven-based projects we parent. This is of particular importance while > managing and cutting releases from multiple repositories. > See `README.adoc` for the complete list of features and their usage. > > See [this `logging-log4j-tools` GitHub Actions workflow > run](https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > demonstrating a successful release cut using a SNAPSHOT version of > this `logging-parent` release. All preparations (release notes, > distribution ZIP, vote & announcement emails, etc.) are staged to both > Nexus and SVN and waiting the release manager to proceed. As a matter > of fact, this very release of `logging-parent` is cut by the very same > reusables too. > > ## Changes > > ### Added > > * Added `changelog-export` profile to easily export changelogs to Markdown > files > * Added `changelog-release` profile to easily move > `src/changelog/.?.x.x` contents to their associated release directory > * Added `deploy` profile to ease the Maven `deploy` goal > * Added `distribution` profile to easily create a distribution file > containing Git-tracked sources, release notes, binary attachments, > `NOTICE.txt`, etc. > * Documented release instructions (i.e., `RELEASING.md`) > * Added `release` profile to share common release-specific Maven configuration > * Added reusable GitHub Actions workflows to share CI boilerplate for > other repositories > * Switched to using `log4j-changelog-maven-plugin` for managing > changelog and release notes
Re: [VOTE] Release Apache Logging Parent 1.10.0
I want to switch to semantic versioning to make it clear what is a bug fix, what introduces new features, etc. I plan to make bug fix releases more often to smoothen the release process of parented projects. Though I see your point regarding `9 > 1.10.0`. If you think this is a blocker and we should rather go with `9.1.0`, etc. instead, please let me know. On Tue, Sep 5, 2023 at 6:45 PM Matt Sicker wrote: > This doesn’t exactly match the versioning scheme for logging-parent which > was a simple integer. This version number is considered much lower than the > latest release by Maven as a result. > > > On Sep 4, 2023, at 2:33 PM, Volkan Yazıcı wrote: > > > > This is a vote to release the Apache Logging Parent 1.10.0. > > > > Source repository: https://github.com/apache/logging-parent > > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > > Distribution: https://dist.apache.org/repos/dist/dev/logging > > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > Please download, test, and cast your votes on this mailing 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 various improvements that we expect to > > relieve the load on `pom.xml` and GitHub Actions workflows of > > Maven-based projects we parent. This is of particular importance while > > managing and cutting releases from multiple repositories. > > See `README.adoc` for the complete list of features and their usage. > > > > See [this `logging-log4j-tools` GitHub Actions workflow > > run]( > https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > > demonstrating a successful release cut using a SNAPSHOT version of > > this `logging-parent` release. All preparations (release notes, > > distribution ZIP, vote & announcement emails, etc.) are staged to both > > Nexus and SVN and waiting the release manager to proceed. As a matter > > of fact, this very release of `logging-parent` is cut by the very same > > reusables too. > > > > ## Changes > > > > ### Added > > > > * Added `changelog-export` profile to easily export changelogs to > Markdown files > > * Added `changelog-release` profile to easily move > > `src/changelog/.?.x.x` contents to their associated release directory > > * Added `deploy` profile to ease the Maven `deploy` goal > > * Added `distribution` profile to easily create a distribution file > > containing Git-tracked sources, release notes, binary attachments, > > `NOTICE.txt`, etc. > > * Documented release instructions (i.e., `RELEASING.md`) > > * Added `release` profile to share common release-specific Maven > configuration > > * Added reusable GitHub Actions workflows to share CI boilerplate for > > other repositories > > * Switched to using `log4j-changelog-maven-plugin` for managing > > changelog and release notes > >
Re: [VOTE] Release Apache Logging Parent 1.10.0
I don’t know enough about how Maven works to say whether it’s a blocker in practice. I’m alright with semantic versioning here in theory at least! > On Sep 5, 2023, at 11:50 AM, Volkan Yazıcı wrote: > > I want to switch to semantic versioning to make it clear what is a bug fix, > what introduces new features, etc. I plan to make bug fix releases more > often to smoothen the release process of parented projects. Though I see > your point regarding `9 > 1.10.0`. If you think this is a blocker and we > should rather go with `9.1.0`, etc. instead, please let me know. > > On Tue, Sep 5, 2023 at 6:45 PM Matt Sicker wrote: > >> This doesn’t exactly match the versioning scheme for logging-parent which >> was a simple integer. This version number is considered much lower than the >> latest release by Maven as a result. >> >>> On Sep 4, 2023, at 2:33 PM, Volkan Yazıcı wrote: >>> >>> This is a vote to release the Apache Logging Parent 1.10.0. >>> >>> Source repository: https://github.com/apache/logging-parent >>> Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c >>> Distribution: https://dist.apache.org/repos/dist/dev/logging >>> Nexus: >> https://repository.apache.org/content/repositories/orgapachelogging-1113 >>> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 >>> >>> Please download, test, and cast your votes on this mailing 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 various improvements that we expect to >>> relieve the load on `pom.xml` and GitHub Actions workflows of >>> Maven-based projects we parent. This is of particular importance while >>> managing and cutting releases from multiple repositories. >>> See `README.adoc` for the complete list of features and their usage. >>> >>> See [this `logging-log4j-tools` GitHub Actions workflow >>> run]( >> https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) >>> demonstrating a successful release cut using a SNAPSHOT version of >>> this `logging-parent` release. All preparations (release notes, >>> distribution ZIP, vote & announcement emails, etc.) are staged to both >>> Nexus and SVN and waiting the release manager to proceed. As a matter >>> of fact, this very release of `logging-parent` is cut by the very same >>> reusables too. >>> >>> ## Changes >>> >>> ### Added >>> >>> * Added `changelog-export` profile to easily export changelogs to >> Markdown files >>> * Added `changelog-release` profile to easily move >>> `src/changelog/.?.x.x` contents to their associated release directory >>> * Added `deploy` profile to ease the Maven `deploy` goal >>> * Added `distribution` profile to easily create a distribution file >>> containing Git-tracked sources, release notes, binary attachments, >>> `NOTICE.txt`, etc. >>> * Documented release instructions (i.e., `RELEASING.md`) >>> * Added `release` profile to share common release-specific Maven >> configuration >>> * Added reusable GitHub Actions workflows to share CI boilerplate for >>> other repositories >>> * Switched to using `log4j-changelog-maven-plugin` for managing >>> changelog and release notes >> >>
Re: [VOTE] Release Apache Logging Parent 1.10.0
Gary, I am not a native speaker, but I find your tone sarcastic. I kindly
ask you to adjust it.
[My comments are inline.]
On Tue, Sep 5, 2023 at 6:21 PM Gary Gregory wrote:
> I should be able to unzip and build, NOT unzip and then scratch my head,
> look for other files like zips and tars...
There is no TAR anywhere. There is only the distribution ZIP containing
`src.zip`, binary files (JARs) and so on. If you prefer `src` in a folder
rather than a compressed file, we can make that happen. The only
downside is those who download a distribution only for the JARs will also
need to reserve disk space for sources too, hence why I put them in a
compressed file. (This convention is practiced by JDK distributions too.)
sigh, this whole dev process is
> getting WORSE.
>
Unless you define what is worse, I cannot address it.
And we want to spread sources in a buch of repos, bleh.
I am the only one in the PMC that agrees with your points regarding
mono-repo, and, together with Piotr, I am trying to find a way forward
without breaking the repository. No decisions have been made yet. I kindly
ask you to understand that everybody is trying to help with their best
intentions.
> All Apache and FOSS projects I've seen just have a src zip with a snapshot
> repo minus some files, not some byzantine structure.
> How is this nested zip mess HELPING users and lowering the bar to entry?
>
I can explain this. This is what
https://dist.apache.org/repos/dist/release/logging/log4j/2.19.0 looks like:
apache-log4j-2.19.0-bin.tar.gz
apache-log4j-2.19.0-bin.tar.gz.asc
apache-log4j-2.19.0-bin.tar.gz.sha256
apache-log4j-2.19.0-bin.tar.gz.sha512
apache-log4j-2.19.0-bin.zip
apache-log4j-2.19.0-bin.zip.asc
apache-log4j-2.19.0-bin.zip.sha256
apache-log4j-2.19.0-bin.zip.sha512
apache-log4j-2.19.0-src.tar.gz
apache-log4j-2.19.0-src.tar.gz.asc
apache-log4j-2.19.0-src.tar.gz.sha256
apache-log4j-2.19.0-src.tar.gz.sha512
apache-log4j-2.19.0-src.zip
apache-log4j-2.19.0-src.zip.asc
apache-log4j-2.19.0-src.zip.sha256
apache-log4j-2.19.0-src.zip.sha512
This is what `log4j-tools/0.4.0` looks like:
apache-log4j-tools-0.4.0.zip
apache-log4j-tools-0.4.0.zip.asc
apache-log4j-tools-0.4.0.zip.sha512
I think the latter is more self-explanatory, compact, and contains
everything the former has.
Why are all the ".githug" files even in the source zip file?
>
There are no `.githug` files. There is a `.github` folder. They are of
particular importance since the reusable CI workflows are part of the
release. They are code used by other projects. They will be versioned and
used by referring to their version.
`src.zip` contains *everything* tracked by Git that is responsible for
making that release happen. It is not a sparse checkout of the actual
repository. That said, Log4j always had it; go and download any
`apache-log4j-*-src.{zip,tar.gz}` of your liking. Hence I am not able to
understand your objection for this particular occasion.
Re: [VOTE] Release Apache Logging Parent 1.10.0
Volkan, as you know I am a native speaker. I don’t find Gary’s ton sarcastic
but frustrated.
That said, asking for input on how it needs to be changed rather than just
complaining is correct.
See my other comments below.
> On Sep 5, 2023, at 10:10 AM, Volkan Yazıcı wrote:
>
> Gary, I am not a native speaker, but I find your tone sarcastic. I kindly
> ask you to adjust it.
>
> [My comments are inline.]
>
> On Tue, Sep 5, 2023 at 6:21 PM Gary Gregory wrote:
>
>> I should be able to unzip and build, NOT unzip and then scratch my head,
>> look for other files like zips and tars...
>
>
> There is no TAR anywhere. There is only the distribution ZIP containing
> `src.zip`, binary files (JARs) and so on. If you prefer `src` in a folder
> rather than a compressed file, we can make that happen. The only
> downside is those who download a distribution only for the JARs will also
> need to reserve disk space for sources too, hence why I put them in a
> compressed file. (This convention is practiced by JDK distributions too.)
>
> sigh, this whole dev process is
>> getting WORSE.
>>
>
> Unless you define what is worse, I cannot address it.
>
> And we want to spread sources in a buch of repos, bleh.
>
>
> I am the only one in the PMC that agrees with your points regarding
> mono-repo, and, together with Piotr, I am trying to find a way forward
> without breaking the repository. No decisions have been made yet. I kindly
> ask you to understand that everybody is trying to help with their best
> intentions.
While I may not totally agree with Gary regarding the mono-repo, I do respect
his point of view. As I have tried to state, I believe Gary sees the mono-repo
as providing some sort of guarantee that isn’t really there, or at least as
much as he thinks it is. I suspect that once you can prove we have a way to
ensure that all log4j components play nice together Gary may not care so much
if there is one repo or 20.
>
>
>> All Apache and FOSS projects I've seen just have a src zip with a snapshot
>> repo minus some files, not some byzantine structure.
>
>
>> How is this nested zip mess HELPING users and lowering the bar to entry?
>>
>
> I can explain this. This is what
> https://dist.apache.org/repos/dist/release/logging/log4j/2.19.0 looks like:
>
> apache-log4j-2.19.0-bin.tar.gz
> apache-log4j-2.19.0-bin.tar.gz.asc
> apache-log4j-2.19.0-bin.tar.gz.sha256
> apache-log4j-2.19.0-bin.tar.gz.sha512
> apache-log4j-2.19.0-bin.zip
> apache-log4j-2.19.0-bin.zip.asc
> apache-log4j-2.19.0-bin.zip.sha256
> apache-log4j-2.19.0-bin.zip.sha512
> apache-log4j-2.19.0-src.tar.gz
> apache-log4j-2.19.0-src.tar.gz.asc
> apache-log4j-2.19.0-src.tar.gz.sha256
> apache-log4j-2.19.0-src.tar.gz.sha512
> apache-log4j-2.19.0-src.zip
> apache-log4j-2.19.0-src.zip.asc
> apache-log4j-2.19.0-src.zip.sha256
> apache-log4j-2.19.0-src.zip.sha512
>
> This is what `log4j-tools/0.4.0` looks like:
>
> apache-log4j-tools-0.4.0.zip
> apache-log4j-tools-0.4.0.zip.asc
> apache-log4j-tools-0.4.0.zip.sha512
>
> I think the latter is more self-explanatory, compact, and contains
> everything the former has.
This is simply a difference of opinion. Historically releases have always
consisted of the zip of the source in one zip and the artifact jars archived
into another zip. This is pretty straightforward and simple. If you now have to
unzip a file and then inspect the results to figure out what is what then this
indeed is not nearly as straightforward as what we were doing.
>
> Why are all the ".githug" files even in the source zip file?
>>
>
> There are no `.githug` files. There is a `.github` folder. They are of
> particular importance since the reusable CI workflows are part of the
> release. They are code used by other projects. They will be versioned and
> used by referring to their version.
>
> `src.zip` contains *everything* tracked by Git that is responsible for
> making that release happen. It is not a sparse checkout of the actual
> repository. That said, Log4j always had it; go and download any
> `apache-log4j-*-src.{zip,tar.gz}` of your liking. Hence I am not able to
> understand your objection for this particular occasion.
Ralph
Re: [VOTE] Release Apache Logging Parent 1.10.0
I'm not a native speaker either, French is my native language.
There is a reason we split src and bin distributions: The former is
required, the latter is not. Binaries tar/zip files are conveniences only,
strictly speaking. Some downstream users (Linux folks) build everything
from first principles, don't need or want pre-built binaries.
On Tue, Sep 5, 2023, 1:10 PM Volkan Yazıcı wrote:
> Gary, I am not a native speaker, but I find your tone sarcastic. I kindly
> ask you to adjust it.
>
> [My comments are inline.]
>
> On Tue, Sep 5, 2023 at 6:21 PM Gary Gregory
> wrote:
>
> > I should be able to unzip and build, NOT unzip and then scratch my head,
> > look for other files like zips and tars...
>
>
> There is no TAR anywhere. There is only the distribution ZIP containing
> `src.zip`, binary files (JARs) and so on. If you prefer `src` in a folder
> rather than a compressed file, we can make that happen. The only
> downside is those who download a distribution only for the JARs will also
> need to reserve disk space for sources too, hence why I put them in a
> compressed file. (This convention is practiced by JDK distributions too.)
>
> sigh, this whole dev process is
> > getting WORSE.
> >
>
> Unless you define what is worse, I cannot address it.
>
> And we want to spread sources in a buch of repos, bleh.
>
>
> I am the only one in the PMC that agrees with your points regarding
> mono-repo, and, together with Piotr, I am trying to find a way forward
> without breaking the repository. No decisions have been made yet. I kindly
> ask you to understand that everybody is trying to help with their best
> intentions.
>
>
> > All Apache and FOSS projects I've seen just have a src zip with a
> snapshot
> > repo minus some files, not some byzantine structure.
>
>
> > How is this nested zip mess HELPING users and lowering the bar to entry?
> >
>
> I can explain this. This is what
> https://dist.apache.org/repos/dist/release/logging/log4j/2.19.0 looks
> like:
>
> apache-log4j-2.19.0-bin.tar.gz
> apache-log4j-2.19.0-bin.tar.gz.asc
> apache-log4j-2.19.0-bin.tar.gz.sha256
> apache-log4j-2.19.0-bin.tar.gz.sha512
> apache-log4j-2.19.0-bin.zip
> apache-log4j-2.19.0-bin.zip.asc
> apache-log4j-2.19.0-bin.zip.sha256
> apache-log4j-2.19.0-bin.zip.sha512
> apache-log4j-2.19.0-src.tar.gz
> apache-log4j-2.19.0-src.tar.gz.asc
> apache-log4j-2.19.0-src.tar.gz.sha256
> apache-log4j-2.19.0-src.tar.gz.sha512
> apache-log4j-2.19.0-src.zip
> apache-log4j-2.19.0-src.zip.asc
> apache-log4j-2.19.0-src.zip.sha256
> apache-log4j-2.19.0-src.zip.sha512
>
> This is what `log4j-tools/0.4.0` looks like:
>
> apache-log4j-tools-0.4.0.zip
> apache-log4j-tools-0.4.0.zip.asc
> apache-log4j-tools-0.4.0.zip.sha512
>
> I think the latter is more self-explanatory, compact, and contains
> everything the former has.
>
> Why are all the ".githug" files even in the source zip file?
> >
>
> There are no `.githug` files. There is a `.github` folder. They are of
> particular importance since the reusable CI workflows are part of the
> release. They are code used by other projects. They will be versioned and
> used by referring to their version.
>
> `src.zip` contains *everything* tracked by Git that is responsible for
> making that release happen. It is not a sparse checkout of the actual
> repository. That said, Log4j always had it; go and download any
> `apache-log4j-*-src.{zip,tar.gz}` of your liking. Hence I am not able to
> understand your objection for this particular occasion.
>
Re: [VOTE] Release Apache Logging Parent 1.10.0
1. I don’t understand why there is are email-announce and email-vote text files in the distribution directory. The release notes should be in the distribution itself. 2. As expected I very much dislike the bean shell script in the parent pom. 3. As Matt pointed out, the version number is smaller than the previous version. Since the parent project is just a pom.xml semantic versioning doesn’t really make much sense here. But having a version smaller than the previous version is just not OK. I am -1 on this release due to item 3. I’d be -0.5 otherwise. Question - reading the RELEASING doc is there a reason steps 1-3 can’t be performed by a GitHub action? Where I work we use Jenkins pipelines. We have a “release-create” goal that creates the release branch ready to go. The release branch then shows up in Jenkins as something that can be built via a pipeline (along with dev and master). We then select the release branch and do “build now” to generate a release. When that is completed we run the “release-merge” job. Something like this with GitHub Actions seems more reasonable than the manual steps one still has to do. Ralph > On Sep 4, 2023, at 12:33 PM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Logging Parent 1.10.0. > > Source repository: https://github.com/apache/logging-parent > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > Distribution: https://dist.apache.org/repos/dist/dev/logging > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing 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 various improvements that we expect to > relieve the load on `pom.xml` and GitHub Actions workflows of > Maven-based projects we parent. This is of particular importance while > managing and cutting releases from multiple repositories. > See `README.adoc` for the complete list of features and their usage. > > See [this `logging-log4j-tools` GitHub Actions workflow > run](https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > demonstrating a successful release cut using a SNAPSHOT version of > this `logging-parent` release. All preparations (release notes, > distribution ZIP, vote & announcement emails, etc.) are staged to both > Nexus and SVN and waiting the release manager to proceed. As a matter > of fact, this very release of `logging-parent` is cut by the very same > reusables too. > > ## Changes > > ### Added > > * Added `changelog-export` profile to easily export changelogs to Markdown > files > * Added `changelog-release` profile to easily move > `src/changelog/.?.x.x` contents to their associated release directory > * Added `deploy` profile to ease the Maven `deploy` goal > * Added `distribution` profile to easily create a distribution file > containing Git-tracked sources, release notes, binary attachments, > `NOTICE.txt`, etc. > * Documented release instructions (i.e., `RELEASING.md`) > * Added `release` profile to share common release-specific Maven configuration > * Added reusable GitHub Actions workflows to share CI boilerplate for > other repositories > * Switched to using `log4j-changelog-maven-plugin` for managing > changelog and release notes
Re: [VOTE] Release Apache Logging Parent 1.10.0
Check. I will split `src` and `bin`.
On Tue, Sep 5, 2023 at 8:31 PM Gary Gregory wrote:
> I'm not a native speaker either, French is my native language.
>
> There is a reason we split src and bin distributions: The former is
> required, the latter is not. Binaries tar/zip files are conveniences only,
> strictly speaking. Some downstream users (Linux folks) build everything
> from first principles, don't need or want pre-built binaries.
>
> On Tue, Sep 5, 2023, 1:10 PM Volkan Yazıcı wrote:
>
> > Gary, I am not a native speaker, but I find your tone sarcastic. I kindly
> > ask you to adjust it.
> >
> > [My comments are inline.]
> >
> > On Tue, Sep 5, 2023 at 6:21 PM Gary Gregory
> > wrote:
> >
> > > I should be able to unzip and build, NOT unzip and then scratch my
> head,
> > > look for other files like zips and tars...
> >
> >
> > There is no TAR anywhere. There is only the distribution ZIP containing
> > `src.zip`, binary files (JARs) and so on. If you prefer `src` in a folder
> > rather than a compressed file, we can make that happen. The only
> > downside is those who download a distribution only for the JARs will also
> > need to reserve disk space for sources too, hence why I put them in a
> > compressed file. (This convention is practiced by JDK distributions too.)
> >
> > sigh, this whole dev process is
> > > getting WORSE.
> > >
> >
> > Unless you define what is worse, I cannot address it.
> >
> > And we want to spread sources in a buch of repos, bleh.
> >
> >
> > I am the only one in the PMC that agrees with your points regarding
> > mono-repo, and, together with Piotr, I am trying to find a way forward
> > without breaking the repository. No decisions have been made yet. I
> kindly
> > ask you to understand that everybody is trying to help with their best
> > intentions.
> >
> >
> > > All Apache and FOSS projects I've seen just have a src zip with a
> > snapshot
> > > repo minus some files, not some byzantine structure.
> >
> >
> > > How is this nested zip mess HELPING users and lowering the bar to
> entry?
> > >
> >
> > I can explain this. This is what
> > https://dist.apache.org/repos/dist/release/logging/log4j/2.19.0 looks
> > like:
> >
> > apache-log4j-2.19.0-bin.tar.gz
> > apache-log4j-2.19.0-bin.tar.gz.asc
> > apache-log4j-2.19.0-bin.tar.gz.sha256
> > apache-log4j-2.19.0-bin.tar.gz.sha512
> > apache-log4j-2.19.0-bin.zip
> > apache-log4j-2.19.0-bin.zip.asc
> > apache-log4j-2.19.0-bin.zip.sha256
> > apache-log4j-2.19.0-bin.zip.sha512
> > apache-log4j-2.19.0-src.tar.gz
> > apache-log4j-2.19.0-src.tar.gz.asc
> > apache-log4j-2.19.0-src.tar.gz.sha256
> > apache-log4j-2.19.0-src.tar.gz.sha512
> > apache-log4j-2.19.0-src.zip
> > apache-log4j-2.19.0-src.zip.asc
> > apache-log4j-2.19.0-src.zip.sha256
> > apache-log4j-2.19.0-src.zip.sha512
> >
> > This is what `log4j-tools/0.4.0` looks like:
> >
> > apache-log4j-tools-0.4.0.zip
> > apache-log4j-tools-0.4.0.zip.asc
> > apache-log4j-tools-0.4.0.zip.sha512
> >
> > I think the latter is more self-explanatory, compact, and contains
> > everything the former has.
> >
> > Why are all the ".githug" files even in the source zip file?
> > >
> >
> > There are no `.githug` files. There is a `.github` folder. They are of
> > particular importance since the reusable CI workflows are part of the
> > release. They are code used by other projects. They will be versioned and
> > used by referring to their version.
> >
> > `src.zip` contains *everything* tracked by Git that is responsible for
> > making that release happen. It is not a sparse checkout of the actual
> > repository. That said, Log4j always had it; go and download any
> > `apache-log4j-*-src.{zip,tar.gz}` of your liking. Hence I am not able to
> > understand your objection for this particular occasion.
> >
>
Re: [VOTE] Release Apache Logging Parent 1.10.0
[We had a video call with Ralph. There I addressed his points. I will share them here one more time for the record.] 1. We need to upload the generated emails somewhere, hence they are there. Otherwise they are not a part of the distribution. I could have uploaded them as artifacts attached to the GitHub Actions run. I have used this in the past for `logging-log4j-tools` and the experience (i.e., downloading them, unpacking them again, etc.) was more cumbersome compared to using SVN (`svn update` and done). 2. We agreed to move the distribution BeanShell to a Maven plugin residing in `log4j-tools` in the future and stick to the current simple setup for now. 3. I will set the version to `10.0.0`. This indeed warrants an RC2. 4. I will also automate the steps 1-3 in `RELEASING.adoc`. 5. The CI job triggered by a commit to a `release/`-prefixed branch is idempotent and will perform all necessary artifact+distribution staging for every run. Hence, one can perfect the release by simply keep on pushing to `release/x.y.z`. On Tue, Sep 5, 2023 at 8:31 PM Ralph Goers wrote: > 1. I don’t understand why there is are email-announce and email-vote text > files in the distribution directory. The release notes should be in the > distribution itself. > 2. As expected I very much dislike the bean shell script in the parent > pom. > 3. As Matt pointed out, the version number is smaller than the previous > version. Since the parent project is just a pom.xml semantic versioning > doesn’t really make much sense here. But having a version smaller than the > previous version is just not OK. > > I am -1 on this release due to item 3. I’d be -0.5 otherwise. > > Question - reading the RELEASING doc is there a reason steps 1-3 can’t be > performed by a GitHub action? > > Where I work we use Jenkins pipelines. We have a “release-create” goal > that creates the release branch ready to go. The release branch then shows > up in Jenkins as something that can be built via a pipeline (along with dev > and master). We then select the release branch and do “build now” to > generate a release. When that is completed we run the “release-merge” > job. Something like this with GitHub Actions seems more reasonable than > the manual steps one still has to do. > > Ralph > > > > On Sep 4, 2023, at 12:33 PM, Volkan Yazıcı wrote: > > > > This is a vote to release the Apache Logging Parent 1.10.0. > > > > Source repository: https://github.com/apache/logging-parent > > Commit: 3dd83461faa058690a5ed821ee81dfc2d744ec7c > > Distribution: https://dist.apache.org/repos/dist/dev/logging > > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1113 > > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > > > Please download, test, and cast your votes on this mailing 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 various improvements that we expect to > > relieve the load on `pom.xml` and GitHub Actions workflows of > > Maven-based projects we parent. This is of particular importance while > > managing and cutting releases from multiple repositories. > > See `README.adoc` for the complete list of features and their usage. > > > > See [this `logging-log4j-tools` GitHub Actions workflow > > run]( > https://github.com/apache/logging-log4j-tools/actions/runs/6070379396) > > demonstrating a successful release cut using a SNAPSHOT version of > > this `logging-parent` release. All preparations (release notes, > > distribution ZIP, vote & announcement emails, etc.) are staged to both > > Nexus and SVN and waiting the release manager to proceed. As a matter > > of fact, this very release of `logging-parent` is cut by the very same > > reusables too. > > > > ## Changes > > > > ### Added > > > > * Added `changelog-export` profile to easily export changelogs to > Markdown files > > * Added `changelog-release` profile to easily move > > `src/changelog/.?.x.x` contents to their associated release directory > > * Added `deploy` profile to ease the Maven `deploy` goal > > * Added `distribution` profile to easily create a distribution file > > containing Git-tracked sources, release notes, binary attachments, > > `NOTICE.txt`, etc. > > * Documented release instructions (i.e., `RELEASING.md`) > > * Added `release` profile to share common release-specific Maven > configuration > > * Added reusable GitHub Actions workflows to share CI boilerplate for > > other repositories > > * Switched to using `log4j-changelog-maven-plugin` for managing > > changelog and release notes > >
