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
