Syncing `master`

[Piotr P. Karwasz]

Hi all,

As you know `master` is painfully lagging after `release-2.x`. The
main problem is that it is still diverging (in the wrong direction).

In the Tomcat repository you can observe 4 commits within minutes,
addressing the same issue in all 4 supported branches. Can we do
something similar in Log4j? What I mean is, whenever a commit occurs
on the `master` or `release-2.x` branches we:

* either receive 2 e-mails in a short timespan (5 minutes?), that
basically mean that we need to prepare 2 commits locally before
pushing it,
* receive 1 e-mail, but the commit message (not necessarily the title)
explains why the other branch has not been touched.

I have been trying to follow this for a couple of months and it is not
always easy: sometimes I can not push a commit/PR to `release-2.x`,
because `master` requires cherry-picking 5 other commits that we
forgot to cherry-pick before. And the commit is deferred by another
day...

"Next" weekend I'll try to write down the sync status of `master` on
the Wiki. I'll break it down into modules and for `log4j-core` into
packages.

Piotr

Re: Syncing `master`

[Piotr P. Karwasz]

Hi,

On Fri, 30 Dec 2022 at 09:47, Piotr P. Karwasz  wrote:
> "Next" weekend I'll try to write down the sync status of `master` on
> the Wiki. I'll break it down into modules and for `log4j-core` into
> packages.

That is actually something I can do in a couple of minutes:

https://cwiki.apache.org/confluence/display/LOGGING/Master+branch+synchronization+status

I'll fill in the table with the module/packages I already checked in
the next few days. I invite you to do the same.

Piotr

Re: Maven site failure

[Volkan Yazıcı]

Agreed.

Ralph, I see that you have only added `true` to
`log4j-layout-template-json-test` module, why don't we add it to all
`*-test` and `*-its` modules? That is, `log4j-api-test`, `log4j-core-its`,
`log4j-core-test`, etc.

On Fri, Dec 30, 2022 at 1:45 AM Ralph Goers 
wrote:

>
>
> > On Dec 29, 2022, at 5:44 PM, Ralph Goers 
> wrote:
> >
> > I am trying to build the web site and it is failing in the javadoc
> plugin in log4j-layout-template-json-test because there are public or
> protected classes to document. Either the javadoc plugin needs to be
> disabled for the module or some classes need to be made public.
>
> Personally, I don’t think any of the test modules need javadoc generated.
>
> Ralph

Re: Maven site failure

[Gary Gregory]

Should that setting be flipped such that a Maven module ask to be Javadoc'd?

Gary

On Fri, Dec 30, 2022, 07:23 Volkan Yazıcı  wrote:

> Agreed.
>
> Ralph, I see that you have only added `true` to
> `log4j-layout-template-json-test` module, why don't we add it to all
> `*-test` and `*-its` modules? That is, `log4j-api-test`, `log4j-core-its`,
> `log4j-core-test`, etc.
>
> On Fri, Dec 30, 2022 at 1:45 AM Ralph Goers 
> wrote:
>
> >
> >
> > > On Dec 29, 2022, at 5:44 PM, Ralph Goers 
> > wrote:
> > >
> > > I am trying to build the web site and it is failing in the javadoc
> > plugin in log4j-layout-template-json-test because there are public or
> > protected classes to document. Either the javadoc plugin needs to be
> > disabled for the module or some classes need to be made public.
> >
> > Personally, I don’t think any of the test modules need javadoc generated.
> >
> > Ralph
>

Re: Syncing `master`

[Volkan Yazıcı]

What I am missing most is a baseline. If there would have been a `3.x`
release right after a `2.y` release, I could have taken `3.x` as a baseline
and whenever `2.(y+1)` comes out, I would make sure `3.(x+1)` contains all
the changes from `2.y` to `2.(y+1)`. In its current state, talking about
the parity between `release-2.x` and `master` feels to me nothing but a
well-educated guess.

I know, this is not really constructive for the question at hand, but my
point is, a 3.x release would ease the problem and might render the need to
nudge committers with emails and such redundant.

I support your efforts for aligning the two branches and keeping a progress
report in Confluence.


On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> As you know `master` is painfully lagging after `release-2.x`. The
> main problem is that it is still diverging (in the wrong direction).
>
> In the Tomcat repository you can observe 4 commits within minutes,
> addressing the same issue in all 4 supported branches. Can we do
> something similar in Log4j? What I mean is, whenever a commit occurs
> on the `master` or `release-2.x` branches we:
>
> * either receive 2 e-mails in a short timespan (5 minutes?), that
> basically mean that we need to prepare 2 commits locally before
> pushing it,
> * receive 1 e-mail, but the commit message (not necessarily the title)
> explains why the other branch has not been touched.
>
> I have been trying to follow this for a couple of months and it is not
> always easy: sometimes I can not push a commit/PR to `release-2.x`,
> because `master` requires cherry-picking 5 other commits that we
> forgot to cherry-pick before. And the commit is deferred by another
> day...
>
> "Next" weekend I'll try to write down the sync status of `master` on
> the Wiki. I'll break it down into modules and for `log4j-core` into
> packages.
>
> Piotr
>

Re: [log4cxx] Next steps / release?

[Tobias Frost]

On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote:
> IF an SONAME bump is required, it will become more challenging, as other
> Debian teams are involved (and other maintainers if it casues breakages in
> reverse dependencies)
> I would basically needs something (it does not need to be the final
> release, just something with the target SONAME) now to kick of the process. 
> Fixes
> (without SONAME bump) can still then be provided until February.

Ok, I've compiled the new version and the version currently in Debian and
threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with
8 errors.

I've put the report here:  
https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html

1 = old version, currently in debian
2 = new version "head" of current git, master-branch.

Level::initializeLevels ( ) should not be deleted…

On the other erros, where registers have changed, I have no idea what's going 
on…


[1] https://github.com/lvc/abi-compliance-checker

 
 -- 
 Cheers,
 tobi
> 
>  
> > -Robert Middleton
> > 
> > [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7

Re: Maven site failure

[Apache]

False is the default so I left it alone. It also means it is specified in less 
places.

Ralph

> On Dec 30, 2022, at 5:26 AM, Gary Gregory  wrote:
> 
> Should that setting be flipped such that a Maven module ask to be Javadoc'd?
> 
> Gary
> 
>> On Fri, Dec 30, 2022, 07:23 Volkan Yazıcı  wrote:
>> 
>> Agreed.
>> 
>> Ralph, I see that you have only added `true` to
>> `log4j-layout-template-json-test` module, why don't we add it to all
>> `*-test` and `*-its` modules? That is, `log4j-api-test`, `log4j-core-its`,
>> `log4j-core-test`, etc.
>> 
>> On Fri, Dec 30, 2022 at 1:45 AM Ralph Goers 
>> wrote:
>> 
>>> 
>>> 
 On Dec 29, 2022, at 5:44 PM, Ralph Goers 
>>> wrote:
 
 I am trying to build the web site and it is failing in the javadoc
>>> plugin in log4j-layout-template-json-test because there are public or
>>> protected classes to document. Either the javadoc plugin needs to be
>>> disabled for the module or some classes need to be made public.
>>> 
>>> Personally, I don’t think any of the test modules need javadoc generated.
>>> 
>>> Ralph
>> 

Re: [log4cxx] Next steps / release?

[Robert Middleton]

On Fri, Dec 30, 2022 at 10:17 AM Tobias Frost  wrote:
>
> On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote:
> > IF an SONAME bump is required, it will become more challenging, as other
> > Debian teams are involved (and other maintainers if it casues breakages in
> > reverse dependencies)
> > I would basically needs something (it does not need to be the final
> > release, just something with the target SONAME) now to kick of the process. 
> > Fixes
> > (without SONAME bump) can still then be provided until February.
>
> Ok, I've compiled the new version and the version currently in Debian and
> threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with
> 8 errors.
>
> I've put the report here:  
> https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html
>
> 1 = old version, currently in debian
> 2 = new version "head" of current git, master-branch.
>
> Level::initializeLevels ( ) should not be deleted…
>
> On the other erros, where registers have changed, I have no idea what's going 
> on…
>

The registers changing sounds like something in the compiler changed.
But it looks like that's on master, where what we're talking about
here is currently in the next_stable branch(which should have a
ridiculous number of ABI failures, but it should still be
source-compatible).

-Robert Middleton

Re: [log4cxx] Next steps / release?

[Tobias Frost]

On Fri, Dec 30, 2022 at 10:29:46AM -0500, Robert Middleton wrote:
> On Fri, Dec 30, 2022 at 10:17 AM Tobias Frost  wrote:
> >
> > On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote:
> > > IF an SONAME bump is required, it will become more challenging, as other
> > > Debian teams are involved (and other maintainers if it casues breakages in
> > > reverse dependencies)
> > > I would basically needs something (it does not need to be the final
> > > release, just something with the target SONAME) now to kick of the 
> > > process. Fixes
> > > (without SONAME bump) can still then be provided until February.
> >
> > Ok, I've compiled the new version and the version currently in Debian and
> > threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with
> > 8 errors.
> >
> > I've put the report here:  
> > https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html
> >
> > 1 = old version, currently in debian
> > 2 = new version "head" of current git, master-branch.
> >
> > Level::initializeLevels ( ) should not be deleted…
> >
> > On the other erros, where registers have changed, I have no idea what's 
> > going on…
> >
> 
> The registers changing sounds like something in the compiler changed.

Both versions were freshly compiled, with the same compiler and using the same
"debian/rules"

> But it looks like that's on master, where what we're talking about
> here is currently in the next_stable branch(which should have a
> ridiculous number of ABI failures,

Yes, https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html
was from the branch "master" to 0.13.0 (as in "from the release tarball" [1])

When doing the same against the branch "next_stable", currently at [2]
the result is much much worse:
https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html

/me confused… (I've read your text as it should be the opposite…)


[1] sha256sum log4cxx_0.13.0.orig.tar.gz
4e5be64b6b1e6de8525f8b87635270b81f772a98902d20d7ac646fdf1ac08284  
log4cxx_0.13.0.orig.tar.gz

[2] commit ad751d5fc523205e47fda013df0ff51691eaffb3 (HEAD -> next_stable, 
origin/next_stable)
Author: Stephen Webb 
Date:   Fri Dec 30 16:17:56 2022 +1100

Prevent compilation error when the log4cxx user uses a different C++ 
standard to the log4cxx build

The result is much much worse:
https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html


> but it should still be source-compatible).

If it is only API compatible, but not ABI compable, we'll need a SONAME bump.


> 
> -Robert Middleton

Cheers,
-- 
tobi


signature.asc
Description: PGP signature

Re: [log4cxx] Next steps / release?

[Robert Middleton]

On Fri, Dec 30, 2022 at 11:43 AM Tobias Frost  wrote:
> When doing the same against the branch "next_stable", currently at [2]
> the result is much much worse:
> https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html
>
> /me confused… (I've read your text as it should be the opposite…)
>

The new version should be ABI stable moving forward, but it needs to
be released first.

> If it is only API compatible, but not ABI compable, we'll need a SONAME bump.
>

I bumped the SONAME a little bit ago; you probably grabbed the code
shortly before I bumped it.  I think I've done it correctly, but it
would be nice to have somebody double-check it.  I arbitrarily bumped
it to version 15, skipping 14.  The version of the SO file should also
now match the version of log4cxx, but that version is not the same as
the SONAME.

-Robert Middleton

Re: Syncing `master`

[Matt Sicker]

I agree with Volkan; this will be a bit easier to handle once we start cutting 
3.x releases. We can better define the baseline there.
—
Matt Sicker

> On Dec 30, 2022, at 06:37, Volkan Yazıcı  wrote:
> 
> What I am missing most is a baseline. If there would have been a `3.x`
> release right after a `2.y` release, I could have taken `3.x` as a baseline
> and whenever `2.(y+1)` comes out, I would make sure `3.(x+1)` contains all
> the changes from `2.y` to `2.(y+1)`. In its current state, talking about
> the parity between `release-2.x` and `master` feels to me nothing but a
> well-educated guess.
> 
> I know, this is not really constructive for the question at hand, but my
> point is, a 3.x release would ease the problem and might render the need to
> nudge committers with emails and such redundant.
> 
> I support your efforts for aligning the two branches and keeping a progress
> report in Confluence.
> 
> 
> On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi all,
>> 
>> As you know `master` is painfully lagging after `release-2.x`. The
>> main problem is that it is still diverging (in the wrong direction).
>> 
>> In the Tomcat repository you can observe 4 commits within minutes,
>> addressing the same issue in all 4 supported branches. Can we do
>> something similar in Log4j? What I mean is, whenever a commit occurs
>> on the `master` or `release-2.x` branches we:
>> 
>> * either receive 2 e-mails in a short timespan (5 minutes?), that
>> basically mean that we need to prepare 2 commits locally before
>> pushing it,
>> * receive 1 e-mail, but the commit message (not necessarily the title)
>> explains why the other branch has not been touched.
>> 
>> I have been trying to follow this for a couple of months and it is not
>> always easy: sometimes I can not push a commit/PR to `release-2.x`,
>> because `master` requires cherry-picking 5 other commits that we
>> forgot to cherry-pick before. And the commit is deferred by another
>> day...
>> 
>> "Next" weekend I'll try to write down the sync status of `master` on
>> the Wiki. I'll break it down into modules and for `log4j-core` into
>> packages.
>> 
>> Piotr
>> 

Re: Syncing `master`

[Ralph Goers]

Talking about what might have helped in the past isn’t going to be very useful. 
For one, we didn’t cut releases on master because there were too many things 
not yet done. That isn’t the case any more. 

It is annoying to know commits were made to 2.x that weren’t also committed to 
master. I still don’t know why anyone would do that, but again knowing that 
isn’t helpful.

What matters is determining where they are out of sync so we can get a 
3.0.0-alpha1 release cut.

Ralph

> On Dec 30, 2022, at 1:25 PM, Matt Sicker  wrote:
> 
> I agree with Volkan; this will be a bit easier to handle once we start 
> cutting 3.x releases. We can better define the baseline there.
> —
> Matt Sicker
> 
>> On Dec 30, 2022, at 06:37, Volkan Yazıcı  wrote:
>> 
>> What I am missing most is a baseline. If there would have been a `3.x`
>> release right after a `2.y` release, I could have taken `3.x` as a baseline
>> and whenever `2.(y+1)` comes out, I would make sure `3.(x+1)` contains all
>> the changes from `2.y` to `2.(y+1)`. In its current state, talking about
>> the parity between `release-2.x` and `master` feels to me nothing but a
>> well-educated guess.
>> 
>> I know, this is not really constructive for the question at hand, but my
>> point is, a 3.x release would ease the problem and might render the need to
>> nudge committers with emails and such redundant.
>> 
>> I support your efforts for aligning the two branches and keeping a progress
>> report in Confluence.
>> 
>> 
>> On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> As you know `master` is painfully lagging after `release-2.x`. The
>>> main problem is that it is still diverging (in the wrong direction).
>>> 
>>> In the Tomcat repository you can observe 4 commits within minutes,
>>> addressing the same issue in all 4 supported branches. Can we do
>>> something similar in Log4j? What I mean is, whenever a commit occurs
>>> on the `master` or `release-2.x` branches we:
>>> 
>>> * either receive 2 e-mails in a short timespan (5 minutes?), that
>>> basically mean that we need to prepare 2 commits locally before
>>> pushing it,
>>> * receive 1 e-mail, but the commit message (not necessarily the title)
>>> explains why the other branch has not been touched.
>>> 
>>> I have been trying to follow this for a couple of months and it is not
>>> always easy: sometimes I can not push a commit/PR to `release-2.x`,
>>> because `master` requires cherry-picking 5 other commits that we
>>> forgot to cherry-pick before. And the commit is deferred by another
>>> day...
>>> 
>>> "Next" weekend I'll try to write down the sync status of `master` on
>>> the Wiki. I'll break it down into modules and for `log4j-core` into
>>> packages.
>>> 
>>> Piotr
>>> 
> 

Re: Syncing `master`

[Ralph Goers]

I am not understanding the format of this table. I expected it to contain a 
list of PRs/Jira issues that were not propagated. Instead it seems to be a list 
of modules and package names. Are we supposed to mark the packages that have 
been validated?

Ralph

> On Dec 30, 2022, at 2:36 AM, Piotr P. Karwasz  wrote:
> 
> Hi,
> 
> On Fri, 30 Dec 2022 at 09:47, Piotr P. Karwasz  
> wrote:
>> "Next" weekend I'll try to write down the sync status of `master` on
>> the Wiki. I'll break it down into modules and for `log4j-core` into
>> packages.
> 
> That is actually something I can do in a couple of minutes:
> 
> https://cwiki.apache.org/confluence/display/LOGGING/Master+branch+synchronization+status
> 
> I'll fill in the table with the module/packages I already checked in
> the next few days. I invite you to do the same.
> 
> Piotr

Re: Log4Net 2.014

[Robert Middleton]

Kevin,

I don't work on Log4net, but looking through the recent commits it
looks like this may have been fixed:
https://github.com/apache/logging-log4net/pull/92

I don't know if there is currently a timeline as to when this might be
officially released.

-Robert Middleton

On Thu, Dec 29, 2022 at 5:17 PM Ralph Goers  wrote:
>
> Rupak and Kevin,
>
> Please note that your emails contain a classification that these are internal 
> Schwab emails but that you have sent them to a public mailing list. We 
> obviously ignore such classifications since there is no way to make them 
> private once you have done that.
>
> I can’t comment on your specific issue as I don’t work on Log4Net so I will 
> leave that to those that do.
>
> Ralph
>
> > On Dec 29, 2022, at 1:24 PM, Seal, Rupak  
> > wrote:
> >
> > HI @Tools Support is there any ways to have 
> > this work being escalated as this impacted production stability and 
> > damaging the logging server in Production SNE environment
> >
> > From: Gardenhire, Kevin 
> > Date: Thursday, December 29, 2022 at 2:12 PM
> > To: dev@logging.apache.org 
> > Cc: Joshi, Hemant , Vishwakarma, Amit 
> > , Seal, Rupak , 
> > Shambhumane, Meenakshi 
> > Subject: Log4Net 2.014
> > Hi,
> >
> > We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate 
> > a security flaw found in the old package. After upgrading we have found an 
> > issue that is not allowing 2 instances of an application to write to the 
> > same file location. We have a blue/green pool deployment strategy where 
> > each server has an active and inactive application instance and on the 
> > first deployment we see that the active version logs as expected, but after 
> > swapping the pools the new active application is unable to log as the now 
> > inactive application seems to have a lock on the file.
> >
> > We were able to make it work with 2.0.3, but 2.0.10 is the oldest version 
> > that does not have the flaw. Any versions of the library without the flaw 
> > has this locking issue.
> >
> > Can you help us to raise an issue to be taken up for development in future 
> > releases?
> >
> > Thanks,
> > Kevin Gardenhire
> > Charles Schwab & Co.  |  Enterprise Middleware and Online Security 
> > Technology (EMOST)
> >
> >
> >
> > Classification: Schwab Internal
> >
> >
> > Classification: Schwab Internal
>