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 <piotr.karw...@gmail.com> 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 >
