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 <m...@musigma.org> 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ı <vol...@yazi.ci> 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 <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 >>> >
