Re: Syncing `master`

[Volkan Yazıcı <vo...@yazi.ci>]

Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
telling commit X needs to be reflected on branch Y whenever a commit lands
on branch Z?

If you all agree, I volunteer to set this up.

On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz <pi...@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
>

Re: Syncing `master`

[Ralph Goers <ra...@dslextreme.com>]

I don’t necessarily object to this version of the proposal. While not perfect it should eliminate most of the noise.

Ralph

> On Jan 3, 2023, at 2:01 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> That sounds like a great sweet spot to settle on. We can periodically
> (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> commits older than 24 hours have a subject-matching counterpart in `master`
> (and vice versa), if not, creates a GitHub Issue assigned to the author of
> the commit and referencing to the commit.
> 
> Anybody else objecting, except Ralph?
> 
> On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <pi...@gmail.com>
> wrote:
> 
>> Hi Volkan,
>> 
>> On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
>>> telling commit X needs to be reflected on branch Y whenever a commit
>> lands
>>> on branch Z?
>>> 
>>> If you all agree, I volunteer to set this up.
>> 
>> If you can add a time delay, that would be fantastic.
>> 
>> I imagine some logic like: if 24 hours have passed and the commit with
>> a subject line "Hello World!" on `release-2.x` does not have a commit
>> in `master` with the same subject, create an issue. Commits that need
>> a subject change (like "Deprecate for removal" -> "Remove") are rare
>> and a committer can always close those issues manually.
>> 
>> Piotr
>> 

Re: Syncing `master`

[Volkan Yazıcı <vo...@yazi.ci>]

I assume such cases to be relatively infrequent. If not, we can introduce a
commit message magic word to disarm the mechanism. All in all, is clicking
on the _Close_ button of a ticket really that difficult?

Note that these tickets would also constitute a good historical account for
hinting the divergence between multiple release branches.

On Tue, Jan 3, 2023 at 12:20 PM Gary Gregory <ga...@gmail.com> wrote:

> Sounds like it could backfire in some cases creating busy work: What
> happens when I commit to 2.x for code that has been deprecated or removed
> in 3.x? Certainly we don't want to create tickets for those. Do I have to
> remember to put a special comment in the commit message?
>
> Gary
>
> On Tue, Jan 3, 2023, 04:01 Volkan Yazıcı <vo...@yazi.ci> wrote:
>
> > That sounds like a great sweet spot to settle on. We can periodically
> > (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> > commits older than 24 hours have a subject-matching counterpart in
> `master`
> > (and vice versa), if not, creates a GitHub Issue assigned to the author
> of
> > the commit and referencing to the commit.
> >
> > Anybody else objecting, except Ralph?
> >
> > On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <
> piotr.karwasz@gmail.com>
> > wrote:
> >
> > > Hi Volkan,
> > >
> > > On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > > > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > > > telling commit X needs to be reflected on branch Y whenever a commit
> > > lands
> > > > on branch Z?
> > > >
> > > > If you all agree, I volunteer to set this up.
> > >
> > > If you can add a time delay, that would be fantastic.
> > >
> > > I imagine some logic like: if 24 hours have passed and the commit with
> > > a subject line "Hello World!" on `release-2.x` does not have a commit
> > > in `master` with the same subject, create an issue. Commits that need
> > > a subject change (like "Deprecate for removal" -> "Remove") are rare
> > > and a committer can always close those issues manually.
> > >
> > > Piotr
> > >
> >
>

Re: Syncing `master`

[Gary Gregory <ga...@gmail.com>]

Sounds like it could backfire in some cases creating busy work: What
happens when I commit to 2.x for code that has been deprecated or removed
in 3.x? Certainly we don't want to create tickets for those. Do I have to
remember to put a special comment in the commit message?

Gary

On Tue, Jan 3, 2023, 04:01 Volkan Yazıcı <vo...@yazi.ci> wrote:

> That sounds like a great sweet spot to settle on. We can periodically
> (hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
> commits older than 24 hours have a subject-matching counterpart in `master`
> (and vice versa), if not, creates a GitHub Issue assigned to the author of
> the commit and referencing to the commit.
>
> Anybody else objecting, except Ralph?
>
> On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <pi...@gmail.com>
> wrote:
>
> > Hi Volkan,
> >
> > On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > > telling commit X needs to be reflected on branch Y whenever a commit
> > lands
> > > on branch Z?
> > >
> > > If you all agree, I volunteer to set this up.
> >
> > If you can add a time delay, that would be fantastic.
> >
> > I imagine some logic like: if 24 hours have passed and the commit with
> > a subject line "Hello World!" on `release-2.x` does not have a commit
> > in `master` with the same subject, create an issue. Commits that need
> > a subject change (like "Deprecate for removal" -> "Remove") are rare
> > and a committer can always close those issues manually.
> >
> > Piotr
> >
>

Re: Syncing `master`

[Volkan Yazıcı <vo...@yazi.ci>]

That sounds like a great sweet spot to settle on. We can periodically
(hourly?) run a GitHub Actions workflow that checks if all `release-2.x`
commits older than 24 hours have a subject-matching counterpart in `master`
(and vice versa), if not, creates a GitHub Issue assigned to the author of
the commit and referencing to the commit.

Anybody else objecting, except Ralph?

On Mon, Jan 2, 2023 at 11:19 PM Piotr P. Karwasz <pi...@gmail.com>
wrote:

> Hi Volkan,
>
> On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vo...@yazi.ci> wrote:
> > Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> > telling commit X needs to be reflected on branch Y whenever a commit
> lands
> > on branch Z?
> >
> > If you all agree, I volunteer to set this up.
>
> If you can add a time delay, that would be fantastic.
>
> I imagine some logic like: if 24 hours have passed and the commit with
> a subject line "Hello World!" on `release-2.x` does not have a commit
> in `master` with the same subject, create an issue. Commits that need
> a subject change (like "Deprecate for removal" -> "Remove") are rare
> and a committer can always close those issues manually.
>
> Piotr
>

Re: Syncing `master`

["Piotr P. Karwasz" <pi...@gmail.com>]

Hi Volkan,

On Mon, 2 Jan 2023 at 09:50, Volkan Yazıcı <vo...@yazi.ci> wrote:
> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> telling commit X needs to be reflected on branch Y whenever a commit lands
> on branch Z?
>
> If you all agree, I volunteer to set this up.

If you can add a time delay, that would be fantastic.

I imagine some logic like: if 24 hours have passed and the commit with
a subject line "Hello World!" on `release-2.x` does not have a commit
in `master` with the same subject, create an issue. Commits that need
a subject change (like "Deprecate for removal" -> "Remove") are rare
and a committer can always close those issues manually.

Piotr

Re: Syncing `master`

[Ralph Goers <ra...@dslextreme.com>]

That seems impractical as it will result in every commit creating a new issue since it isn’t possible to commit to both branches at once.

Ralph

> On Jan 2, 2023, at 1:50 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> Suggestion: Shall we harness GitHub Actions to create a GitHub Issue
> telling commit X needs to be reflected on branch Y whenever a commit lands
> on branch Z?
> 
> If you all agree, I volunteer to set this up.
> 
> On Fri, Dec 30, 2022 at 9:48 AM Piotr P. Karwasz <pi...@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
>>