Merge stable to master vs cherry-picking

[Ahmad Samir]

On 8/12/21 01:08, Sandro Knauß wrote:
> Hi,
> 
>>> Fixing it in master means i have to build a zillion of repositories before
>>> even trying to start fixing the bug, it may also happen that once I built
>>> master i can't reproduce the bug because master has been fixed for various
>>> reasons (re-architecture, fixed the bug and forgot to cherry-pick, etc)
> 
>>> Fixing it in the stable branch is much easier, just build the kmail repo
>>> and fix the bug.
> 
> I fully agree: merge stable is much clearer and easier.

Until you have to use git-bisect, then the merge commits are a pain in the neck sometimes.

> 
>> Maybe I'm missing something but in case which You described, You will still
>> need to build all that from master branch to propose patch from stable to
>> master. Otherwise how You will know if patch needs to be in master or maybe
>> it's already fixed in other way there?
> 
> Well for kdepim master means: I need the newest KDE Frameworks available, my
> distro is not that fast shipping them every month. Than I need to build the
> complete pimstack, as you cannot mix different version. This is a lot of work
> just to fix one bug I know that isn't addressed ;) And the bugs are nasty when
> you only see them once in while, so you need to run your fix for several days
> to make sure something is fixed. That's why it is that hard to run it from
> master branch.

Fix in stable then cherry-pick to master? either it's going to apply cleanly or with small 
conflicts, or it's going to involve more work to apply. If the merge-stable-to-master works, I don't 
know why cherry-picking a commit (or a range of commits) wouldn't work.

I am more accustomed to the KF workflow, there is no stable branch, it's master and release every 
month; with the "leaf" apps, Konsole, Dolphin, Kate ...etc, fixing in master then cherry picking to 
stable isn't an issue, whereas with PIM, it's more of a bundle/suite of libs/apps.

So PIM is a special case in this regard.

> I think that the entrace barrier is higher, when we only have cherry-picking
> and that means that even less people are able to fix kdepim.
> I think especially for newcommers and drive-by committers it is much easier to
> be able to just rebuilt one repo instead of a complete stack.
> 
> My gut feeling is that git is smarter when you merge than cherry-pick. If
> there are renames or code refactoring happing in master than merge strategy is
> more reliable. At least I get often very small issues when merging stable.
> 
> One big argument against cherry-picking is that you are never know if
> everything is inside master because the branches have differnt commits. When
> merging stable to master, than you can be sure that everything changed on
> stable is in master.
> 
> Cheers,
> 
> sandro
> 
> 
> 


-- 
Ahmad Samir