[log4cxx] next_stable and other fixes

[Robert Middleton <rm...@apache.org>]

Just as a note to all, what I've been doing with next_stable is to
periodically merge master back in once I make fixes on master(assuming
that those fixes are common to both).  Unfortunately with the
multithreaded speed fix this has resulted in a moderately sized merge
conflict.  I think I've fixed everything to work properly at this
point.

What should our workflow be?  Is there a better way?  Obviously there
are certain things that would only target next_stable and not master,
so I'm not thinking about those cases for this.

-Robert Middleton

Re: [log4cxx] next_stable and other fixes

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag Stephen Webb,
am Dienstag, 4. Januar 2022 um 04:51 schrieben Sie:

> Once the branches diverge, git cherry-pick is the better merge process.

They have diverged already and all changes from master were decided to
be useful in next_stable. So the results of cherry-picking and
merging would be identical right now anyway. Additonally, diverging
branches increase the risk of smaller cherry-picks to not apply
cleanly as well.

I don't see how this can be avoided besides saying to mostly NOT
merge/cherry-pick at all and only do so exceptionally. But if the
merged changes were useful in general for next_stable...

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: Thorsten.Schoening@AM-SoFT.de
Web:    http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska

Re: [log4cxx] next_stable and other fixes

[Stephen Webb <sw...@gmail.com>]

Once the branches diverge, git cherry-pick is the better merge process.

On Tue, Jan 4, 2022 at 11:06 AM Robert Middleton <rm...@apache.org>
wrote:

> Just as a note to all, what I've been doing with next_stable is to
> periodically merge master back in once I make fixes on master(assuming
> that those fixes are common to both).  Unfortunately with the
> multithreaded speed fix this has resulted in a moderately sized merge
> conflict.  I think I've fixed everything to work properly at this
> point.
>
> What should our workflow be?  Is there a better way?  Obviously there
> are certain things that would only target next_stable and not master,
> so I'm not thinking about those cases for this.
>
> -Robert Middleton
>