Re: [log4j] Performance figures

[Remko Popma]

I’m open to improvements in this area. 

Before going into details or specifics though, I’m curious:

What do we (users, developers and PMC members) consider to be the “value 
proposition” of Log4j? Why should people choose Log4j over the alternatives? 

This is a positioning question; what are the strengths and weaknesses of Log4j 
and how should Log4j position itself in the market of logging solutions?

Remko


> On Jan 15, 2024, at 22:05, Gary Gregory  wrote:
> 
> We should IMO keep this information available _somewhere_, maybe in a new
> stable historical-archival section of the site. I'm not a fan of using the
> wiki because that's yet another place to look for information and it feels
> transitory, unstable (as far as information permanance), and more like
> something we should use (if at all) as a scratch pad.
> 
> Gary
> 
>> On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:
>> 
>> *TLDR:* I want to remove performance figures from the Log4j website,
>> because they don't serve any practical value anymore.
>> 
>> Log4j website shares performance figures in several pages; Performance
>> ,
>> Asynchronous
>> Logging
>> <
>> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
>>> ,
>> Garbage-free Logging
>>  are among
>> the well-known ones. I want to remove all performance figures and only keep
>> pragmatic recommendations due to following reasons:
>> 
>>   - *Insufficient relevancy* – Shared figures were mostly produced using
>>   Log4j version `2.5` and `2.6`. These releases date back from late 2016
>> and
>>   *a lot* has changed since then.
>>   - *Insufficient reliability* – There were many occasions PMC members
>>   stated they weren't able to reproduce these figures.
>>   - *Error prone* – As tipped in the website, measuring performance
>>   correctly is very difficult
>>   .
>>   - *Context dependent* – Performance is an extremely subjective term. It
>>   requires context. What kind of an application? What is the application
>>   load? What is the logging load? What is the logging setup? etc. Sharing
>> a
>>   meaningful figure here that users can benefit in any way is, IMHO,
>>   impossible.
>>   - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if
>>   any of the existing performance figures (produced using ~8 year old
>> Log4j)
>>   are applicable to Log4j 3.
>> 
>> Will we have no performance figures at all? AFAIC, we need to have a
>> continuous performance testbed that would not only give users an indication
>> about performance of Log4j over time (in a reproducible way!), but also,
>> maybe more importantly, guide maintainers on making changes affecting
>> performance. Some of you might recall: I already had implemented some stuff
>> on this subject and had a "a continuous performance testbed"  project in my
>> first STF projects draft. But we needed to drop it due to other pressing
>> issues and insufficient budget. We can bring it up again if need (and
>> budget?) arises. Let me know if you and/or your employer would be
>> interested in funding such an effort.
>> 

Re: [log4j] `.asf.yaml` between branches

[Piotr P. Karwasz]

Hi Ralph,

On Tue, 16 Jan 2024 at 01:56, Ralph Goers  wrote:
>
> I don’t understand what it means to keep both staging and publish in 
> “asf-site”. By definition, the asf-site branch is the live web-site and 
> asf-staging is the staging web site.  Are you talking about the build scripts 
> or something?

We are talking about this `.asf.yaml` content:

publish:
  profile: ~
  whoami: asf-site
  subdir: content/logging-parent

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/logging-parent

Due to the `whoami` attribute, the `.asf.yaml` file on both the
`asf-site` and `asf-staging` branch can be the same. INFRA will ignore
the `staging` instruction on `asf-site` and the `publish` instruction
on `asf-staging`.

Piotr

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

[Ralph Goers]

I am OK with this. It would be best if we could get Tomcat to publish a 
tomcat-log4j artifact.

Ralph

> On Jan 15, 2024, at 1:50 PM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> While 3.x is approaching its first stable release as a meteor burning
> through the sky, its core is getting smaller as it approaches earth.
> 
> That is why I would propose to remove two further modules from 3.x:
> 
> * The functionality of `log4j-jcl` is included in `commons-logging`
> version 1.3.0 (and previously it was also provided by `spring-jcl`). I
> assume that users migrating to Log4j 3.x can also migrate to
> `commons-logging` 1.3.0.
> 
> * The Jetty 9.x logger, which is half of the functionality of
> `log4j-appserver`, can be replaced by `log4j-slf4j-impl` if the users
> are willing to migrate to Jetty 10.x. Since community support for
> Jetty 9.x ended two years ago, I guess user will migrate to a
> supported Jetty version first and only then think about Log4j 3.x.
> 
> * The Tomcat logger (the other half of `log4j-appserver`) is only
> part of the puzzle of artifacts required to have a fully functional
> logging system in Tomcat. I usually also needed my own artifacts from
> copernik-eu/log4j-plugins[1] to have something comparable (but still
> worse) than what WildFly has. I can adopt this part of
> `log4j-appserver` into copernik-eu/log4j-plugins and make a release
> before Log4j 3.0.0 is out. If there is any user interest in it, I can
> "contribute back" the Tomcat logger and other components in a future
> release.
> 
> What do you think?
> 
> [1] https://github.com/copernik-eu/log4j-plugins

Re: [log4j] `.asf.yaml` between branches

[Ralph Goers]

I don’t understand what it means to keep both staging and publish in 
“asf-site”. By definition, the asf-site branch is the live web-site and 
asf-staging is the staging web site.  Are you talking about the build scripts 
or something? 

I started to reply to this earlier today but got sidetracked with my day job. 

To be honest, I still prefer the repo per web site model but I am OK with any 
solution that:
* is 100% consistent no matter which web site it is. 
* doesn’t require a Confluence page or Readme to locate the web site source for 
a project

By consistent I mean that if it is using branches then the branch name follows 
a pattern such as asf-site-2.x and asf-staged-2.x even if we are only 
publishing a single version of the web site for the project.

Ralph

> On Jan 15, 2024, at 11:52 AM, Volkan Yazıcı  wrote:
> 
> Even though it wouldn't be of my preference, keeping both `staging` and
> `publish` configuration in `asf-site` sounds like a middle ground I can
> live with. I will appreciate it if you can adapt your existing changes (in
> `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless
> you have already done so.
> 
> On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz 
> wrote:
> 
>> Hi Volkan,
>> 
>> On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı  wrote:
 * you can stage the website for a release with a simple:
 
 git checkout asf-staging
 git reset --hard asf-site
 unzip ...
 git push -f
 
>>> 
>>> You can do the same in the existing setup too. You just need a `sed`
>>> one-liner to adapt the `.asf.yaml` content:
>>> 
>>> $ sed -i -e 's/^publish:/staging:/g' -e 's/^  whoami:.+/  :whoami:
>>> asf-staging/g' asf.yaml
>>> 
>>> Not to mention this is a detail that will be a part of the CI-based
>> release
>>> process. That is, no PMC member will need to recall or type any of these
>>> `git`, `sed`, `unzip`, etc. commands to cut a release.
>>> 
>>> Given I addressed your "quickly stage a website" concern, are we good?
>> 
>> I agree with your objections on not **requiring** all `.asf.yaml` to
>> be in sync. However I also don't see a reason not to have a `staging`
>> configuration on the `asf-site` branch and a `publish` configuration
>> on the `asf-staging` branch.
>> 
>> I would prefer for the CI not to meddle with critical files such as
>> `.asf.yaml`, especially if changes to these files are almost never
>> required.
>> 
>> Piotr
>> 
>> PS: I removed the `publish` and `staging` sections on the main branch
>> of `logging-parent` and the `github` section on the site branches.
>> 

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

[Volkan Yazıcı]

+1

Allow me to remind everyone that anything that is removed from `3.0.0` can
be added again in a follow up minor release, if need arises. Hence, no need
to be overcautious.

On Mon, Jan 15, 2024 at 9:50 PM Piotr P. Karwasz 
wrote:

> Hi all,
>
> While 3.x is approaching its first stable release as a meteor burning
> through the sky, its core is getting smaller as it approaches earth.
>
> That is why I would propose to remove two further modules from 3.x:
>
>  * The functionality of `log4j-jcl` is included in `commons-logging`
> version 1.3.0 (and previously it was also provided by `spring-jcl`). I
> assume that users migrating to Log4j 3.x can also migrate to
> `commons-logging` 1.3.0.
>
>  * The Jetty 9.x logger, which is half of the functionality of
> `log4j-appserver`, can be replaced by `log4j-slf4j-impl` if the users
> are willing to migrate to Jetty 10.x. Since community support for
> Jetty 9.x ended two years ago, I guess user will migrate to a
> supported Jetty version first and only then think about Log4j 3.x.
>
>  * The Tomcat logger (the other half of `log4j-appserver`) is only
> part of the puzzle of artifacts required to have a fully functional
> logging system in Tomcat. I usually also needed my own artifacts from
> copernik-eu/log4j-plugins[1] to have something comparable (but still
> worse) than what WildFly has. I can adopt this part of
> `log4j-appserver` into copernik-eu/log4j-plugins and make a release
> before Log4j 3.0.0 is out. If there is any user interest in it, I can
> "contribute back" the Tomcat logger and other components in a future
> release.
>
> What do you think?
>
> [1] https://github.com/copernik-eu/log4j-plugins
>

[log4j] Remove `XmlLayout` from `main`

[Volkan Yazıcı]

I asked Gary if he can re-evaluate his decision on `XmlLayout`, since he
was the only one who requested to keep it in `main`. He kindly checked this
in his employer's codebase, could not locate any `XmlLayout` usage, and
agreed to drop it from `main`. (Thank you Gary! ) I will implement this
change, FYI.

On Fri, Nov 3, 2023 at 10:08 PM Gary Gregory  wrote:

> Hi Volkan,
>
> I only care about XML.
>
> Gary
>
>
> On Fri, Nov 3, 2023, 3:27 PM Volkan Yazıcı  wrote:
>
>> Gary, do you want to keep all Jackson modules or just XmlLayout?
>>
>> -- Forwarded message -
>> From: Volkan Yazıcı 
>> Date: Thu, 2 Nov 2023 at 16:43
>> Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and
>> removal in 3.x
>> To: 
>>
>>
>> On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
>> wrote:
>>
>>> > On Nov 2, 2023, at 7:42 AM, Gary Gregory 
>>> wrote:
>>> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>>> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> > -1: I want the ability to log to XML (narrow use-case, sure, but
>>> handy).
>>
>>
>> Gary, do you only want to keep `XmlLayout` or all 3?
>>
>

Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

[Piotr P. Karwasz]

Hi all,

While 3.x is approaching its first stable release as a meteor burning
through the sky, its core is getting smaller as it approaches earth.

That is why I would propose to remove two further modules from 3.x:

 * The functionality of `log4j-jcl` is included in `commons-logging`
version 1.3.0 (and previously it was also provided by `spring-jcl`). I
assume that users migrating to Log4j 3.x can also migrate to
`commons-logging` 1.3.0.

 * The Jetty 9.x logger, which is half of the functionality of
`log4j-appserver`, can be replaced by `log4j-slf4j-impl` if the users
are willing to migrate to Jetty 10.x. Since community support for
Jetty 9.x ended two years ago, I guess user will migrate to a
supported Jetty version first and only then think about Log4j 3.x.

 * The Tomcat logger (the other half of `log4j-appserver`) is only
part of the puzzle of artifacts required to have a fully functional
logging system in Tomcat. I usually also needed my own artifacts from
copernik-eu/log4j-plugins[1] to have something comparable (but still
worse) than what WildFly has. I can adopt this part of
`log4j-appserver` into copernik-eu/log4j-plugins and make a release
before Log4j 3.0.0 is out. If there is any user interest in it, I can
"contribute back" the Tomcat logger and other components in a future
release.

What do you think?

[1] https://github.com/copernik-eu/log4j-plugins

Re: [log4j] `.asf.yaml` between branches

[Volkan Yazıcı]

Even though it wouldn't be of my preference, keeping both `staging` and
`publish` configuration in `asf-site` sounds like a middle ground I can
live with. I will appreciate it if you can adapt your existing changes (in
`logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless
you have already done so.

On Mon, Jan 15, 2024 at 12:27 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı  wrote:
> > >  * you can stage the website for a release with a simple:
> > >
> > > git checkout asf-staging
> > > git reset --hard asf-site
> > > unzip ...
> > > git push -f
> > >
> >
> > You can do the same in the existing setup too. You just need a `sed`
> > one-liner to adapt the `.asf.yaml` content:
> >
> > $ sed -i -e 's/^publish:/staging:/g' -e 's/^  whoami:.+/  :whoami:
> > asf-staging/g' asf.yaml
> >
> > Not to mention this is a detail that will be a part of the CI-based
> release
> > process. That is, no PMC member will need to recall or type any of these
> > `git`, `sed`, `unzip`, etc. commands to cut a release.
> >
> > Given I addressed your "quickly stage a website" concern, are we good?
>
> I agree with your objections on not **requiring** all `.asf.yaml` to
> be in sync. However I also don't see a reason not to have a `staging`
> configuration on the `asf-site` branch and a `publish` configuration
> on the `asf-staging` branch.
>
> I would prefer for the CI not to meddle with critical files such as
> `.asf.yaml`, especially if changes to these files are almost never
> required.
>
> Piotr
>
> PS: I removed the `publish` and `staging` sections on the main branch
> of `logging-parent` and the `github` section on the site branches.
>

Re: [log4j] Performance figures

[Gary Gregory]

We should IMO keep this information available _somewhere_, maybe in a new
stable historical-archival section of the site. I'm not a fan of using the
wiki because that's yet another place to look for information and it feels
transitory, unstable (as far as information permanance), and more like
something we should use (if at all) as a scratch pad.

Gary

On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:

> *TLDR:* I want to remove performance figures from the Log4j website,
> because they don't serve any practical value anymore.
>
> Log4j website shares performance figures in several pages; Performance
> ,
> Asynchronous
> Logging
> <
> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
> >,
> Garbage-free Logging
>  are among
> the well-known ones. I want to remove all performance figures and only keep
> pragmatic recommendations due to following reasons:
>
>- *Insufficient relevancy* – Shared figures were mostly produced using
>Log4j version `2.5` and `2.6`. These releases date back from late 2016
> and
>*a lot* has changed since then.
>- *Insufficient reliability* – There were many occasions PMC members
>stated they weren't able to reproduce these figures.
>- *Error prone* – As tipped in the website, measuring performance
>correctly is very difficult
>.
>- *Context dependent* – Performance is an extremely subjective term. It
>requires context. What kind of an application? What is the application
>load? What is the logging load? What is the logging setup? etc. Sharing
> a
>meaningful figure here that users can benefit in any way is, IMHO,
>impossible.
>- *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if
>any of the existing performance figures (produced using ~8 year old
> Log4j)
>are applicable to Log4j 3.
>
> Will we have no performance figures at all? AFAIC, we need to have a
> continuous performance testbed that would not only give users an indication
> about performance of Log4j over time (in a reproducible way!), but also,
> maybe more importantly, guide maintainers on making changes affecting
> performance. Some of you might recall: I already had implemented some stuff
> on this subject and had a "a continuous performance testbed"  project in my
> first STF projects draft. But we needed to drop it due to other pressing
> issues and insufficient budget. We can bring it up again if need (and
> budget?) arises. Let me know if you and/or your employer would be
> interested in funding such an effort.
>

[log4j] Performance figures

[Volkan Yazıcı]

*TLDR:* I want to remove performance figures from the Log4j website,
because they don't serve any practical value anymore.

Log4j website shares performance figures in several pages; Performance
,
Asynchronous
Logging
,
Garbage-free Logging
 are among
the well-known ones. I want to remove all performance figures and only keep
pragmatic recommendations due to following reasons:

   - *Insufficient relevancy* – Shared figures were mostly produced using
   Log4j version `2.5` and `2.6`. These releases date back from late 2016 and
   *a lot* has changed since then.
   - *Insufficient reliability* – There were many occasions PMC members
   stated they weren't able to reproduce these figures.
   - *Error prone* – As tipped in the website, measuring performance
   correctly is very difficult
   .
   - *Context dependent* – Performance is an extremely subjective term. It
   requires context. What kind of an application? What is the application
   load? What is the logging load? What is the logging setup? etc. Sharing a
   meaningful figure here that users can benefit in any way is, IMHO,
   impossible.
   - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if
   any of the existing performance figures (produced using ~8 year old Log4j)
   are applicable to Log4j 3.

Will we have no performance figures at all? AFAIC, we need to have a
continuous performance testbed that would not only give users an indication
about performance of Log4j over time (in a reproducible way!), but also,
maybe more importantly, guide maintainers on making changes affecting
performance. Some of you might recall: I already had implemented some stuff
on this subject and had a "a continuous performance testbed"  project in my
first STF projects draft. But we needed to drop it due to other pressing
issues and insufficient budget. We can bring it up again if need (and
budget?) arises. Let me know if you and/or your employer would be
interested in funding such an effort.

Re: [log4j] `.asf.yaml` between branches

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı  wrote:
> >  * you can stage the website for a release with a simple:
> >
> > git checkout asf-staging
> > git reset --hard asf-site
> > unzip ...
> > git push -f
> >
>
> You can do the same in the existing setup too. You just need a `sed`
> one-liner to adapt the `.asf.yaml` content:
>
> $ sed -i -e 's/^publish:/staging:/g' -e 's/^  whoami:.+/  :whoami:
> asf-staging/g' asf.yaml
>
> Not to mention this is a detail that will be a part of the CI-based release
> process. That is, no PMC member will need to recall or type any of these
> `git`, `sed`, `unzip`, etc. commands to cut a release.
>
> Given I addressed your "quickly stage a website" concern, are we good?

I agree with your objections on not **requiring** all `.asf.yaml` to
be in sync. However I also don't see a reason not to have a `staging`
configuration on the `asf-site` branch and a `publish` configuration
on the `asf-staging` branch.

I would prefer for the CI not to meddle with critical files such as
`.asf.yaml`, especially if changes to these files are almost never
required.

Piotr

PS: I removed the `publish` and `staging` sections on the main branch
of `logging-parent` and the `github` section on the site branches.

Re: Website repos/branches (again)

[Piotr P. Karwasz]

On Mon, 15 Jan 2024 at 10:40, Volkan Yazıcı  wrote:
>
> -1 on merging multiple websites to a single repository.
>
> I think documentation should reside in the same repository where sources
> are. I already implemented this for *almost* every repository:
>
> logging-parent
> logging-log4j-tools
> logging-log4j-transform
> logging-log4j-kotlin
> logging-log4j-scala
> logging-log4j-jakarta
>
> There is only one left to migrate to this scheme: `logging-log4j2`, which I
> intend to do on February 9 during STF MS12. `logging-site`, `cyclonedx`,
> `activity-monitor` are exceptions, since they are only websites, not source
> code repositories. Hence, your statement of *"the way our website is
> created from multiple repos and branches is somehow incoherent"* is untrue.

I am fine with this scheme if it becomes universal.

Regarding `logging-log4j2`, we will probably need 2 pairs of website
branches, so that we can publish `/log4j/2.x` and `/log4j/3.x`
independently. The `/log4j` folder can be published from
`logging-site`.

Piotr

Re: [log4j] `.asf.yaml` between branches

[Volkan Yazıcı]

On Mon, Jan 15, 2024 at 9:45 AM Piotr P. Karwasz 
wrote:

> This setup has some pros:
>
>  * you don't need to navigate to all the website branches to see how
> they are configured,
>

This would only work *iff* the `.asf.yaml` between the branch you are
looking at (e.g., `main`) and the target branch (e.g. `asf-site`) do match.
This is an assumption and an extra maintenance task. We both witnessed
several of such assumptions were unheld while refactoring the existing
Log4j websites. Not just I fixed several `.asf.yaml` files, I even deleted
long forgotten website branches.


>  * you can stage the website for a release with a simple:
>
> git checkout asf-staging
> git reset --hard asf-site
> unzip ...
> git push -f
>

You can do the same in the existing setup too. You just need a `sed`
one-liner to adapt the `.asf.yaml` content:

$ sed -i -e 's/^publish:/staging:/g' -e 's/^  whoami:.+/  :whoami:
asf-staging/g' asf.yaml

Not to mention this is a detail that will be a part of the CI-based release
process. That is, no PMC member will need to recall or type any of these
`git`, `sed`, `unzip`, etc. commands to cut a release.

Given I addressed your "quickly stage a website" concern, are we good?

So maybe we could use a mixed approach:
>
>  * the Github config can only be on a single branch,
>  * the website config is copied to every branch.
>

All in all, I am against assumptions and extra maintenance tasks. You and I
have been working on Log4j full time for several months. This might not be
the case next year anymore. People come and go. I value the simplicity and
ease of maintenance above all in community projects.


> What do you think? See also my e-mail on the site repo/branches mess.
> I doubt most PMC members can tell you where each part of the website
> is coming from.
>

As I explained in my response to your other email, the *"site repo/branches
mess"* statement is not true. Besides a few exceptions I shared, the
*"`asf-{site,staging}`
branch of every repository points to the website"* scheme is clear enough
for everyone, IMO.

Re: Website repos/branches (again)

[Volkan Yazıcı]

-1 on merging multiple websites to a single repository.

I think documentation should reside in the same repository where sources
are. I already implemented this for *almost* every repository:

logging-parent
logging-log4j-tools
logging-log4j-transform
logging-log4j-kotlin
logging-log4j-scala
logging-log4j-jakarta

There is only one left to migrate to this scheme: `logging-log4j2`, which I
intend to do on February 9 during STF MS12. `logging-site`, `cyclonedx`,
`activity-monitor` are exceptions, since they are only websites, not source
code repositories. Hence, your statement of *"the way our website is
created from multiple repos and branches is somehow incoherent"* is untrue.

Using *"site next to sources"* scheme, when one checks out a repository, it
is crystal clear what goes where:

- the `asf-site` branch for `logging.apache.org`
- the `asf-staging` branch for `logging.staged.apache.org`
- the rest of the branches for the source code

This scheme would enable many benefits:

   1. Contributors, maintainers, users, etc. can easily locate the site and
   submit changes with zero a priori knowledge. Cloned the sources? Ready to
   go.
   2. Since all Maven-based projects would be sharing the same site scheme,
   we can automate the website publication in the CI-based release process.

Those who are concerned about folder structure deviation between
`afs-{site,staging}` branches and the rest, all you need is a Git worktree:

$ git clone g...@github.com:
apache/logging-log4j-tools.git logging-log4j-tools~main
$ cd logging-log4j-tools~main
$ git checkout -B asf-site origin/asf-site
$ git checkout -B asf-staging origin/asf-staging
$ git worktree add ../logging-log4j-tools~site asf-site

On Mon, Jan 15, 2024 at 9:34 AM Piotr P. Karwasz 
wrote:

> Hi,
>
> As we discussed yesterday the way our website is created from multiple
> repos and branches is somehow incoherent: some parts of the website
> have separate repos, other parts have a branch in a code repo, other
> parts have a branch in a website repo.
>
> For example:
>
> * the `/log4j/jakarta` directory is published from the `asf-site`
> branch of the `logging-log4j-jakarta` repo (which also contains the
> code of Log4j Jakarta),
>  * the `/cyclonedx` directory is published from the `cyclonedx` branch
> of the `logging-site` repo,
>  * the `/log4j` directory is published from the `asf-site` branch of
> the `logging-log4j-site` repo (dedicated site repo).
>
> This is getting confusing and we need some kind of list to find the
> repo/branch combination responsible for each part of the site.
>
> I think we should bring some order to it. Since not all the parts of
> the website are connected to a code repo, my personal preference would
> be to have everything in `logging-site`, with branches named like:
>
> asf-site
> cyclonedx/asf-site
> log4j/asf-site
> log4j/2.x/asf-site
> log4j/jakarta/asf-site
>
> Putting an `asf-site` (or another suffix) is a Git requirement since
> Git does not allow us to have both `asf-site` and `asf-site/log4j`
> branches.
>
> Anyway, any other convention is good for me, as long as the rules to
> find the correct branch are not too convoluted.
>
> Piotr
>

[ANNOUNCE] Apache Logging Parent 10.6.0 released

[Piotr P. Karwasz]

Apache Logging Parent team is pleased to announce the 10.6.0
release. This project contains the parent POM for other Maven-based
Apache Logging Services projects. For further information (support,
download, etc.) see the project website[1].

=== Release Notes

This minor release contains several small changes to the build pipeline.

Most notably it bans wildcard imports from source code, which will
require expanding those imports before upgrading `logging-parent`.


 Added

* Add JSpecify to dependency management. (#88)
* Add enforcer rule to ban wildcard imports. All imports must be
expanded to provide better comparison of branches. (#63)

 Changed

* Merge Dependabot PRs instead of closing them. (#82)
* Disable `-jpms-multi-release`[2] BND option. (#93)
* Clean up residual `module-info.class` before compilation. (#90)

 Updated

* Update `com.google.errorprone:error_prone_core` to version `2.24.1` (#89)
* Update `github/codeql-action` to version `3.23.0` (#91)
* Update `org.apache.rat:apache-rat-plugin` to version `0.16` (#92)

[1] https://logging.apache.org/logging-parent
[2] https://bnd.bndtools.org/instructions/jpms-multi-release.html

Re: [log4j] `.asf.yaml` between branches

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı  wrote:
> Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"*
> practice in `logging-parent` too. I find this new setup
>
>- *confusing* – Previously, say, `asf-site` related configuration was
>only in the `asf-site` branch. Now it is in multiple branches of which
>it has no association with.
>- *requiring more work for changes* – If I need to make a change to
>`asf-site`, I need to update in several branches.
>- *prone to causing difficult to solve INFRA issues* – We know INFRA is
>sensitive to configuration overrides that appear in multiple branches.
>
> Hence, I prefer you revert all these changes in all repositories and switch
> back to *"configuration related to branch X goes to branch X"* practice.

This setup has some pros:

 * you don't need to navigate to all the website branches to see how
they are configured,
 * you can stage the website for a release with a simple:

git checkout asf-staging
git reset --hard asf-site
unzip ...
git push -f

I partly agree on your remark regarding INFRA issues: the INFRA script
has problems with the **Github** configuration if we set it on
multiple branches (the scripts run on the default branch, a branch
named `main` and `master`).

However I didn't notice any issues if you copy the **Website**
configuration to multiple branches: the `whoami` parameter has been
introduced exactly for that. INFRA ignores all website configuration
unless `whoami` is equal to the name of the current branch.

So maybe we could use a mixed approach:

 * the Github config can only be on a single branch,
 * the website config is copied to every branch.

What do you think? See also my e-mail on the site repo/branches mess.
I doubt most PMC members can tell you where each part of the website
is coming from.

Piotr

Website repos/branches (again)

[Piotr P. Karwasz]

Hi,

As we discussed yesterday the way our website is created from multiple
repos and branches is somehow incoherent: some parts of the website
have separate repos, other parts have a branch in a code repo, other
parts have a branch in a website repo.

For example:

* the `/log4j/jakarta` directory is published from the `asf-site`
branch of the `logging-log4j-jakarta` repo (which also contains the
code of Log4j Jakarta),
 * the `/cyclonedx` directory is published from the `cyclonedx` branch
of the `logging-site` repo,
 * the `/log4j` directory is published from the `asf-site` branch of
the `logging-log4j-site` repo (dedicated site repo).

This is getting confusing and we need some kind of list to find the
repo/branch combination responsible for each part of the site.

I think we should bring some order to it. Since not all the parts of
the website are connected to a code repo, my personal preference would
be to have everything in `logging-site`, with branches named like:

asf-site
cyclonedx/asf-site
log4j/asf-site
log4j/2.x/asf-site
log4j/jakarta/asf-site

Putting an `asf-site` (or another suffix) is a Git requirement since
Git does not allow us to have both `asf-site` and `asf-site/log4j`
branches.

Anyway, any other convention is good for me, as long as the rules to
find the correct branch are not too convoluted.

Piotr

[log4j] `.asf.yaml` between branches

[Volkan Yazıcı]

Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"*
practice in `logging-parent` too. I find this new setup

   - *confusing* – Previously, say, `asf-site` related configuration was
   only in the `asf-site` branch. Now it is in multiple branches of which
   it has no association with.
   - *requiring more work for changes* – If I need to make a change to
   `asf-site`, I need to update in several branches.
   - *prone to causing difficult to solve INFRA issues* – We know INFRA is
   sensitive to configuration overrides that appear in multiple branches.

Hence, I prefer you revert all these changes in all repositories and switch
back to *"configuration related to branch X goes to branch X"* practice.

On Wed, Dec 27, 2023 at 8:50 AM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> pkarwasz pushed a commit to branch asf-staging
> in repository https://gitbox.apache.org/repos/asf/logging-log4j-kotlin.git
>
> commit ba7e51dee84af097e3246b84238997bc9173aa84
> Author: Piotr P. Karwasz 
> AuthorDate: Wed Dec 27 08:49:51 2023 +0100
>
> Synchronize `.asf.yaml` between site branches
> ---
>  .asf.yaml | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/.asf.yaml b/.asf.yaml
> index 46afaa1..545694d 100644
> --- a/.asf.yaml
> +++ b/.asf.yaml
> @@ -21,3 +21,8 @@ publish:
>profile: ~
>whoami: asf-site
>subdir: content/log4j/kotlin
> +
> +staging:
> +  profile: ~
> +  whoami: asf-staging
> +  subdir: content/log4j/kotlin
>
>