Re: Reroute Dependabot emails to a separate separate list

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 6 Feb 2023 at 08:55, Volkan Yazıcı  wrote:
>
> You can configure dependabot to ignore certain major versions or update
> types
> 
> :
>
> ...
>
> Doesn't this help you with your concern?

That is exactly what I have done:

https://github.com/ppkarwasz/logging-log4j2/blob/2.x/.github/dependabot.yml

My main concern is:

* is this list (mostly) complete?
* for some dependencies (e.g. `slf4j-api`) we use multiple (1.7.25,
latest 1.7.x and latest 2.x) versions depending on the module.

I'll let Dependabot run for a couple of weeks on my fork, before
submitting a PR to the main repo.

Piotr

Re: Reroute Dependabot emails to a separate separate list

[Volkan Yazıcı]

I wouldn't aim for an exhaustive list. Your compilation is better than what
we have right now, which is nothing. If we encounter something new, we can
extend this list.

I think your changes could very well live in the official repository. I
don't think the disruption is big enough to warrant work in a fork. But you
can decide this yourself.

On Mon, Feb 6, 2023 at 9:37 AM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Mon, 6 Feb 2023 at 08:55, Volkan Yazıcı  wrote:
> >
> > You can configure dependabot to ignore certain major versions or update
> > types
> > <
> https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore
> >
> > :
> >
> > ...
> >
> > Doesn't this help you with your concern?
>
> That is exactly what I have done:
>
> https://github.com/ppkarwasz/logging-log4j2/blob/2.x/.github/dependabot.yml
>
> My main concern is:
>
> * is this list (mostly) complete?
> * for some dependencies (e.g. `slf4j-api`) we use multiple (1.7.25,
> latest 1.7.x and latest 2.x) versions depending on the module.
>
> I'll let Dependabot run for a couple of weeks on my fork, before
> submitting a PR to the main repo.
>
> Piotr
>

Re: Reroute Dependabot emails to a separate separate list

[Matt Sicker]

I don’t want to get rid of the bot; it’s very useful. I just don’t want its 
notifications in my inbox, especially since they’re nearly impossible to filter 
without false positives (e.g., I can filter email from the bot itself, but then 
I still get emails from anyone here who interacts with the bot when dealing 
with its PRs which ends up flooding the notifications list, too). It’s simple 
enough to view the pull requests tab on GitHub once in a while to handle 
dependency updates (especially before beginning the release process). The rest 
of the notification activity we get is low volume enough that I should be able 
to follow it on a daily basis (and is how I typically notice new issues filed, 
new pull requests, etc).

> On Feb 6, 2023, at 2:50 AM, Volkan Yazıcı  wrote:
> 
> I wouldn't aim for an exhaustive list. Your compilation is better than what
> we have right now, which is nothing. If we encounter something new, we can
> extend this list.
> 
> I think your changes could very well live in the official repository. I
> don't think the disruption is big enough to warrant work in a fork. But you
> can decide this yourself.
> 
> On Mon, Feb 6, 2023 at 9:37 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Mon, 6 Feb 2023 at 08:55, Volkan Yazıcı  wrote:
>>> 
>>> You can configure dependabot to ignore certain major versions or update
>>> types
>>> <
>> https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#specifying-dependencies-and-versions-to-ignore
>>> 
>>> :
>>> 
>>> ...
>>> 
>>> Doesn't this help you with your concern?
>> 
>> That is exactly what I have done:
>> 
>> https://github.com/ppkarwasz/logging-log4j2/blob/2.x/.github/dependabot.yml
>> 
>> My main concern is:
>> 
>> * is this list (mostly) complete?
>> * for some dependencies (e.g. `slf4j-api`) we use multiple (1.7.25,
>> latest 1.7.x and latest 2.x) versions depending on the module.
>> 
>> I'll let Dependabot run for a couple of weeks on my fork, before
>> submitting a PR to the main repo.
>> 
>> Piotr
>> 

Re: Releases?

[Matt Sicker]

I have not committed the properties change; I did, however, back port some of 
the unrelated changes I had in there to master (though the recycler API update 
is still under review as we figure out if we can simplify that API first). I 
may need to restart some of the properties update into more digestible pieces 
first, though. Other than that, we still have more things to break out of core 
in order to minimize the module dependencies (like the Jackson-related config 
plugins), and that may also imply converting a bunch of test config files to 
JSON or properties files as those would be the built-in config formats without 
either java.xml or Jackson.

> On Feb 4, 2023, at 2:41 PM, Ralph Goers  wrote:
> 
> Is there anything left to do for a 2.20.0 release? I have time to prepare the 
> release this weekend if it is ready.
> 
> What is left before the transformer is released?  Do we have a web site for 
> it set up with benchmark numbers? I’d like to try it with some projects at 
> work.
> 
> Where do we stand on 3.0.0-alpha1? Matt, have you committed the properties 
> changes?
> 
> Ralph

Re: log4j-tools tags, checksums, JDK

[Matt Sicker]

He may be referring to the infra-enforced tag naming scheme where any tags 
prefixed with “rel/“ are immutable and cannot be deleted. If you start with a 
tag like `foo-1.2-rc1` and it passes a release vote, then you’d make an alias 
tag on that tag named `rel/1.2`.

> On Feb 3, 2023, at 4:45 AM, Volkan Yazıcı  wrote:
> 
> Gary, let me address your questions here to avoid polluting the voting
> thread.
> See my comments inline below.
> 
>> A minor note: The tags don't look to me like they are named properly.
>> In other projects, I see and do, for example:
>> 
>> someartifact-1.0.2-rc1 is the tag for an RC
>> rel/someartifact-1.0.2 is the tag for the release where infra makes
>> rel/ tags read-only, at least I'm pretty sure they do.
>> 
>> Having a tag for an RC gives us better traceability IMO.
> 
> A release candidate is a semantical label we give to releases that are not
> yet _closed_ (aka. promoted) in `repository.apache.org`. It is only
> meaningful in the context of a voting process. I have tried to explain this
> in log4j-changelog README
> 
> :
> 
> "Log4j _releases_ and _release candidates_ all get deployed to the same
> _staging repository_. Their `pom.xml` files all contain the same release
> version, e.g., `2.19.0`. There are no `-rc1`, `-rc2`, etc. suffixes in the
> version of a release candidate. Once a release candidate voting reaches a
> consensus for release, associated artifacts simply get promoted from the
> staging to the public repository. Hence, there are [technically] no
> differences between releases and release candidates."
> 
> Therefore, to simplify the cognitive load and implementation, I have no
> mention of RC anywhere for log4j-tools releases. Once CI succeeds deploying
> artifacts to Nexus, both the artifacts and the git tag are set. When PMC
> signals the green light, the release manager simply closes/promotes the
> artifacts in `repository.apache.org`. Since commit IDs are available in the
> voting email, we don't lose any traceability.
> 
> I am confused with your "... is the tag for the release where infra makes"
> statement. What is _infra_ in this context? log4j-tools has no such _infra_.
> 
>> Another minor note: Doubling SHA checksums seems over-the-top in
>> https://dist.apache.org/repos/dist/dev/logging/log4j/ I'd stick to
>> 512.
> 
> Implemented in 486a4151f8c3c11a477930f61d9e1de5a7bad741.
> 
>> it blows up with:
>> ...
>> Unrecognized option: --add-exports
> 
> You should have received a `maven-enforcer-plugin` failure telling that you
> are using Java 8, but the build requires Java 11. Due to 11-specific
> entries in `.mvn/jvm.config` (a mistake from my side), you couldn't even
> run Maven, hence the blow up.
> 
> I have fixed this and added a "Build" section to the README
> in 47012783f9835473729f0695cabebb335f0f5afb
> 
>> I ... hate it when downloads try to take over my tooling.
>> If I unzip the zip file and run what I run every day: 'mvn'
> 
> A build system should impose as minimum requirements from the host machine
> as possible. That is why build tools like Gradle, Maven, Bazel, etc.
> provide _wrappers_. This way the only requirement on the host system
> becomes a JDK and nothing else. This also makes sure everybody (incl. CI!)
> uses the very same build tool – a reproducibility win. Long story short,
> providing and using wrappers is a best-practice.

Re: log4j-tools tags, checksums, JDK

[Ralph Goers]

I’m also a little confused. Volkan says he is creating the release tag during 
the CI release run. That won’t work as we should really avoid deleting tags 
created for releases. If the vote fails all that really should be done is to 
drop the artifacts from the Nexus staging repo. A new release build should 
replace the artifacts at dist.apache.org  and create a 
new release tag.  So when the release is approved the release manager should 
checkout the rc tag and tag it again as rel/n.n.n.

Ralph

> On Feb 6, 2023, at 10:40 AM, Matt Sicker  wrote:
> 
> He may be referring to the infra-enforced tag naming scheme where any tags 
> prefixed with “rel/“ are immutable and cannot be deleted. If you start with a 
> tag like `foo-1.2-rc1` and it passes a release vote, then you’d make an alias 
> tag on that tag named `rel/1.2`.
> 
>> On Feb 3, 2023, at 4:45 AM, Volkan Yazıcı  wrote:
>> 
>> Gary, let me address your questions here to avoid polluting the voting
>> thread.
>> See my comments inline below.
>> 
>>> A minor note: The tags don't look to me like they are named properly.
>>> In other projects, I see and do, for example:
>>> 
>>> someartifact-1.0.2-rc1 is the tag for an RC
>>> rel/someartifact-1.0.2 is the tag for the release where infra makes
>>> rel/ tags read-only, at least I'm pretty sure they do.
>>> 
>>> Having a tag for an RC gives us better traceability IMO.
>> 
>> A release candidate is a semantical label we give to releases that are not
>> yet _closed_ (aka. promoted) in `repository.apache.org`. It is only
>> meaningful in the context of a voting process. I have tried to explain this
>> in log4j-changelog README
>> 
>> :
>> 
>> "Log4j _releases_ and _release candidates_ all get deployed to the same
>> _staging repository_. Their `pom.xml` files all contain the same release
>> version, e.g., `2.19.0`. There are no `-rc1`, `-rc2`, etc. suffixes in the
>> version of a release candidate. Once a release candidate voting reaches a
>> consensus for release, associated artifacts simply get promoted from the
>> staging to the public repository. Hence, there are [technically] no
>> differences between releases and release candidates."
>> 
>> Therefore, to simplify the cognitive load and implementation, I have no
>> mention of RC anywhere for log4j-tools releases. Once CI succeeds deploying
>> artifacts to Nexus, both the artifacts and the git tag are set. When PMC
>> signals the green light, the release manager simply closes/promotes the
>> artifacts in `repository.apache.org`. Since commit IDs are available in the
>> voting email, we don't lose any traceability.
>> 
>> I am confused with your "... is the tag for the release where infra makes"
>> statement. What is _infra_ in this context? log4j-tools has no such _infra_.
>> 
>>> Another minor note: Doubling SHA checksums seems over-the-top in
>>> https://dist.apache.org/repos/dist/dev/logging/log4j/ I'd stick to
>>> 512.
>> 
>> Implemented in 486a4151f8c3c11a477930f61d9e1de5a7bad741.
>> 
>>> it blows up with:
>>> ...
>>> Unrecognized option: --add-exports
>> 
>> You should have received a `maven-enforcer-plugin` failure telling that you
>> are using Java 8, but the build requires Java 11. Due to 11-specific
>> entries in `.mvn/jvm.config` (a mistake from my side), you couldn't even
>> run Maven, hence the blow up.
>> 
>> I have fixed this and added a "Build" section to the README
>> in 47012783f9835473729f0695cabebb335f0f5afb
>> 
>>> I ... hate it when downloads try to take over my tooling.
>>> If I unzip the zip file and run what I run every day: 'mvn'
>> 
>> A build system should impose as minimum requirements from the host machine
>> as possible. That is why build tools like Gradle, Maven, Bazel, etc.
>> provide _wrappers_. This way the only requirement on the host system
>> becomes a JDK and nothing else. This also makes sure everybody (incl. CI!)
>> uses the very same build tool – a reproducibility win. Long story short,
>> providing and using wrappers is a best-practice.
> 

Re: log4j-tools tags, checksums, JDK

[Volkan Yazıcı]

Okay, the mystery is solved. Matt has explained to me on Slack this
documented-who-knows-where[1] feature about `rel/`-prefixed tags.

I have updated the CI script and the release documentation
,
created all necessary tags, and deleted old ones.

[1] None of the following official release guides mention `rel/`-prefixed
git tags: distribution ,
creation , and policy
.

On Fri, Feb 3, 2023 at 11:45 AM Volkan Yazıcı  wrote:

> Gary, let me address your questions here to avoid polluting the voting
> thread.
> See my comments inline below.
>
> > A minor note: The tags don't look to me like they are named properly.
> > In other projects, I see and do, for example:
> >
> > someartifact-1.0.2-rc1 is the tag for an RC
> > rel/someartifact-1.0.2 is the tag for the release where infra makes
> > rel/ tags read-only, at least I'm pretty sure they do.
> >
> > Having a tag for an RC gives us better traceability IMO.
>
> A release candidate is a semantical label we give to releases that are not
> yet _closed_ (aka. promoted) in `repository.apache.org`. It is only
> meaningful in the context of a voting process. I have tried to explain this
> in log4j-changelog README
> 
> :
>
> "Log4j _releases_ and _release candidates_ all get deployed to the same
> _staging repository_. Their `pom.xml` files all contain the same release
> version, e.g., `2.19.0`. There are no `-rc1`, `-rc2`, etc. suffixes in the
> version of a release candidate. Once a release candidate voting reaches a
> consensus for release, associated artifacts simply get promoted from the
> staging to the public repository. Hence, there are [technically] no
> differences between releases and release candidates."
>
> Therefore, to simplify the cognitive load and implementation, I have no
> mention of RC anywhere for log4j-tools releases. Once CI succeeds deploying
> artifacts to Nexus, both the artifacts and the git tag are set. When PMC
> signals the green light, the release manager simply closes/promotes the
> artifacts in `repository.apache.org`. Since commit IDs are available in
> the voting email, we don't lose any traceability.
>
> I am confused with your "... is the tag for the release where infra makes"
> statement. What is _infra_ in this context? log4j-tools has no such _infra_.
>
> > Another minor note: Doubling SHA checksums seems over-the-top in
> > https://dist.apache.org/repos/dist/dev/logging/log4j/ I'd stick to
> > 512.
>
> Implemented in 486a4151f8c3c11a477930f61d9e1de5a7bad741.
>
> > it blows up with:
> > ...
> > Unrecognized option: --add-exports
>
> You should have received a `maven-enforcer-plugin` failure telling that
> you are using Java 8, but the build requires Java 11. Due to 11-specific
> entries in `.mvn/jvm.config` (a mistake from my side), you couldn't even
> run Maven, hence the blow up.
>
> I have fixed this and added a "Build" section to the README
> in 47012783f9835473729f0695cabebb335f0f5afb
>
> > I ... hate it when downloads try to take over my tooling.
> > If I unzip the zip file and run what I run every day: 'mvn'
>
> A build system should impose as minimum requirements from the host machine
> as possible. That is why build tools like Gradle, Maven, Bazel, etc.
> provide _wrappers_. This way the only requirement on the host system
> becomes a JDK and nothing else. This also makes sure everybody (incl. CI!)
> uses the very same build tool – a reproducibility win. Long story short,
> providing and using wrappers is a best-practice.
>

Re: log4j-tools tags, checksums, JDK

[Gary Gregory]

FWIW, the rel/ prefix is mentioned here:
https://commons.apache.org/releases/release.html as well as on the pages of
some other Apache projects.

But not that you could have guessed to look there ;-)

This was announced quite a while back on the infra ML IIRC but now I could
not find it.

Gary

On Mon, Feb 6, 2023, 16:45 Volkan Yazıcı  wrote:

> Okay, the mystery is solved. Matt has explained to me on Slack this
> documented-who-knows-where[1] feature about `rel/`-prefixed tags.
>
> I have updated the CI script and the release documentation
> <
> https://github.com/apache/logging-log4j-tools/commit/06c7205b1c44439e120b39ff7db762ccb35aa69e
> >,
> created all necessary tags, and deleted old ones.
>
> [1] None of the following official release guides mention `rel/`-prefixed
> git tags: distribution ,
> creation , and policy
> .
>
> On Fri, Feb 3, 2023 at 11:45 AM Volkan Yazıcı  wrote:
>
> > Gary, let me address your questions here to avoid polluting the voting
> > thread.
> > See my comments inline below.
> >
> > > A minor note: The tags don't look to me like they are named properly.
> > > In other projects, I see and do, for example:
> > >
> > > someartifact-1.0.2-rc1 is the tag for an RC
> > > rel/someartifact-1.0.2 is the tag for the release where infra makes
> > > rel/ tags read-only, at least I'm pretty sure they do.
> > >
> > > Having a tag for an RC gives us better traceability IMO.
> >
> > A release candidate is a semantical label we give to releases that are
> not
> > yet _closed_ (aka. promoted) in `repository.apache.org`. It is only
> > meaningful in the context of a voting process. I have tried to explain
> this
> > in log4j-changelog README
> > <
> https://github.com/apache/logging-log4j-tools/blob/master/log4j-changelog/README.adoc#i-am-about-to-deploy-a-new-log4j-release-what-shall-i-do
> >
> > :
> >
> > "Log4j _releases_ and _release candidates_ all get deployed to the same
> > _staging repository_. Their `pom.xml` files all contain the same release
> > version, e.g., `2.19.0`. There are no `-rc1`, `-rc2`, etc. suffixes in
> the
> > version of a release candidate. Once a release candidate voting reaches a
> > consensus for release, associated artifacts simply get promoted from the
> > staging to the public repository. Hence, there are [technically] no
> > differences between releases and release candidates."
> >
> > Therefore, to simplify the cognitive load and implementation, I have no
> > mention of RC anywhere for log4j-tools releases. Once CI succeeds
> deploying
> > artifacts to Nexus, both the artifacts and the git tag are set. When PMC
> > signals the green light, the release manager simply closes/promotes the
> > artifacts in `repository.apache.org`. Since commit IDs are available in
> > the voting email, we don't lose any traceability.
> >
> > I am confused with your "... is the tag for the release where infra
> makes"
> > statement. What is _infra_ in this context? log4j-tools has no such
> _infra_.
> >
> > > Another minor note: Doubling SHA checksums seems over-the-top in
> > > https://dist.apache.org/repos/dist/dev/logging/log4j/ I'd stick to
> > > 512.
> >
> > Implemented in 486a4151f8c3c11a477930f61d9e1de5a7bad741.
> >
> > > it blows up with:
> > > ...
> > > Unrecognized option: --add-exports
> >
> > You should have received a `maven-enforcer-plugin` failure telling that
> > you are using Java 8, but the build requires Java 11. Due to 11-specific
> > entries in `.mvn/jvm.config` (a mistake from my side), you couldn't even
> > run Maven, hence the blow up.
> >
> > I have fixed this and added a "Build" section to the README
> > in 47012783f9835473729f0695cabebb335f0f5afb
> >
> > > I ... hate it when downloads try to take over my tooling.
> > > If I unzip the zip file and run what I run every day: 'mvn'
> >
> > A build system should impose as minimum requirements from the host
> machine
> > as possible. That is why build tools like Gradle, Maven, Bazel, etc.
> > provide _wrappers_. This way the only requirement on the host system
> > becomes a JDK and nothing else. This also makes sure everybody (incl.
> CI!)
> > uses the very same build tool – a reproducibility win. Long story short,
> > providing and using wrappers is a best-practice.
> >
>