Move Chainsaw to dormant: Q

[Tim Perry]

Do dormant projects clearly indicate they can be re-animated by a sufficient 
number of active committers?

Thanks, 
Tim

Re: [VOTE] Move Chainsaw to dormant

[Gary Gregory]

+1

Gary

On Mon, Feb 12, 2024 at 4:32 PM Christian Grobmeier
 wrote:
>
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work 
> to be done on this component, but not enough hours can be committed to do 
> that work. To reflect this situation to the user, it is better to move 
> Chainsaw to the dormant section and communicate it as "no longer maintained." 
>  The component can be moved back to the "active" state whenever people are 
> actively working on it. The main branch in the repository will be marked with 
> the new state, but the repository will not be archived for now.
>
> Please note:
>
> [ ] +1, move to dormant
> [ ]  -1, don't because...
>
> I will leave this vote open for the usual 72 hours.
>
> Thank you!
>
> Kind regards,
> Christian

Re: [VOTE] Move Chainsaw to dormant

[Piotr P. Karwasz]

+1

Piotr

On Mon, 12 Feb 2024 at 22:32, Christian Grobmeier  wrote:
>
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work 
> to be done on this component, but not enough hours can be committed to do 
> that work. To reflect this situation to the user, it is better to move 
> Chainsaw to the dormant section and communicate it as "no longer maintained." 
>  The component can be moved back to the "active" state whenever people are 
> actively working on it. The main branch in the repository will be marked with 
> the new state, but the repository will not be archived for now.
>
> Please note:
>
> [ ] +1, move to dormant
> [ ]  -1, don't because...
>
> I will leave this vote open for the usual 72 hours.
>
> Thank you!
>
> Kind regards,
> Christian

Re: [VOTE] Move Chainsaw to dormant

[Ralph Goers]

+1

Ralph

> On Feb 12, 2024, at 2:31 PM, Christian Grobmeier  wrote:
> 
> Hello,
> 
> This vote is to put Chainsaw to the "Dormant" components. There is much work 
> to be done on this component, but not enough hours can be committed to do 
> that work. To reflect this situation to the user, it is better to move 
> Chainsaw to the dormant section and communicate it as "no longer maintained." 
>  The component can be moved back to the "active" state whenever people are 
> actively working on it. The main branch in the repository will be marked with 
> the new state, but the repository will not be archived for now.
> 
> Please note:
> 
> [ ] +1, move to dormant
> [ ]  -1, don't because...
> 
> I will leave this vote open for the usual 72 hours.
> 
> Thank you!
> 
> Kind regards,
> Christian

Re: [VOTE] Move Chainsaw to dormant

[Scott Deboy]

+1

Thanks Christian

Scott

On 2/12/24, Christian Grobmeier  wrote:
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work
> to be done on this component, but not enough hours can be committed to do
> that work. To reflect this situation to the user, it is better to move
> Chainsaw to the dormant section and communicate it as "no longer
> maintained."  The component can be moved back to the "active" state whenever
> people are actively working on it. The main branch in the repository will be
> marked with the new state, but the repository will not be archived for now.
>
> Please note:
>
> [ ] +1, move to dormant
> [ ]  -1, don't because...
>
> I will leave this vote open for the usual 72 hours.
>
> Thank you!
>
> Kind regards,
> Christian
>

[VOTE] Move Chainsaw to dormant

[Christian Grobmeier]

Hello,

This vote is to put Chainsaw to the "Dormant" components. There is much work to 
be done on this component, but not enough hours can be committed to do that 
work. To reflect this situation to the user, it is better to move Chainsaw to 
the dormant section and communicate it as "no longer maintained."  The 
component can be moved back to the "active" state whenever people are actively 
working on it. The main branch in the repository will be marked with the new 
state, but the repository will not be archived for now.

Please note:

[ ] +1, move to dormant
[ ]  -1, don't because...

I will leave this vote open for the usual 72 hours.

Thank you!

Kind regards,
Christian

Re: [log4j] Remove `` in `main`

[Piotr P. Karwasz]

Hi Volkan,

On Mon, 12 Feb 2024 at 20:30, Volkan Yazıcı  wrote:
> `StatusLogger` can be configured in following ways:
>
>1. Passing system properties to the Java process (e.g.,
>`-Dlog4j2.StatusLogger.level=INFO`)
>2. Providing properties in a `log4j2.StatusLogger.properties` file in
>the classpath
>3. Using Log4j configuration (i.e., `dest="out">`) in a `log4j2.xml` in the classpath. This is facilitated by
>`StatusConfiguration`.
>4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)

You missed some of the possibilities:

5. Setting `log4j2.debug` effectively switches the status logger from
ERROR to TRACE. Before Volkan's PR #2249 this was the only way to
debug problems that occur before a configuration is found and loaded:
`log4j2.StatusLogger.level` was a NO-OP,
6. The property `log4j2.defaultStatusLevel` sets the default value of
the "status" property of a configuration.

I support the idea of removing the "status" property from the
configuration. We could reintroduce it later, but only after we figure
out how to set the logging level separately from components of
different configurations.

Piotr

[log4j] Remove `` in `main`

[Volkan Yazıcı]

*Abstract:* I want to remove from `main` the feature that a `Configuration`
(e.g., `` in a `log4j2.xml`)
configuring the `StatusLogger`, and instead, only allow configuration using
properties.

`StatusLogger` can be configured in following ways:

   1. Passing system properties to the Java process (e.g.,
   `-Dlog4j2.StatusLogger.level=INFO`)
   2. Providing properties in a `log4j2.StatusLogger.properties` file in
   the classpath
   3. Using Log4j configuration (i.e., ``) in a `log4j2.xml` in the classpath. This is facilitated by
   `StatusConfiguration`.
   4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)

`StatusConfiguration`-based configuration has certain caveats:

   - There is a time between the first `StatusLogger` access and a
   configuration file (e.g., `log4j2.xml`) read. Hence, there is a time window
   that only the defaults will be effective.
   - `StatusConfiguration` is created per `LoggerContext` and each LC
   mutates the (globally shared!) `StatusLogger`. Hence, the last loaded
   configuration always becomes the effective one.

Given the purpose of `StatusLogger` (i.e., the logger of the logging
system) and above shortcomings related to `StatusConfiguration`, I want to
remove the `StatusConfiguration`-based configuration in `main`. Thoughts?
Objections?

Re: Version 2.23.0 release schedule

[Piotr P. Karwasz]

Hi Gary,

On Mon, 12 Feb 2024 at 13:22, Gary Gregory  wrote:
>
> I'll continue later today to try and fix the set Level issue...

Great! I have created a bug for that:

https://github.com/apache/logging-log4j2/issues/2281

Piotr

Re: Version 2.23.0 release schedule

[Gary Gregory]

I'll continue later today to try and fix the set Level issue...

Gary

On Mon, Feb 12, 2024, 6:15 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> This week I was planning to perform a 2.23.0 release. According to
> Github most of the issues scheduled for this milestone are resolved:
>
> https://github.com/apache/logging-log4j2/milestone/9
>
> Are there any other issues I should be waiting for?
>
> Piotr
>

Re: Version 2.23.0 release schedule

[Volkan Yazıcı]

+1

Once #2280  (fixing the
`2.x` build) and #2278 (Allow arbitrary position of `` element)
 are in, we can put a
ribbon around `2.23.0`.

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

> Hi all,
>
> This week I was planning to perform a 2.23.0 release. According to
> Github most of the issues scheduled for this milestone are resolved:
>
> https://github.com/apache/logging-log4j2/milestone/9
>
> Are there any other issues I should be waiting for?
>
> Piotr
>

Version 2.23.0 release schedule

[Piotr P. Karwasz]

Hi all,

This week I was planning to perform a 2.23.0 release. According to
Github most of the issues scheduled for this milestone are resolved:

https://github.com/apache/logging-log4j2/milestone/9

Are there any other issues I should be waiting for?

Piotr