Merge stable to master vs cherry-picking

[Nate Graham]

I don't have any insights into any technical blockers, but if it is 
technically feasible, I think it would be good to move everything to the 
cherry-pick model due to the following advantages:

1. Unlike the merge-stable-to-master workflow, cherry-picking can be 
done from the GitLab web UI, which is convenient when you're also using 
the web UI to merge. You don't have to leave your web browser.

2. Cherry-picking can be done by the person merging a merge request, 
rather than asking the submitter to rebase and retarget their merge 
request on the stable branch when they (very very commonly) submit a 
bugfix against the master branch. This is a fairly complicated task for 
someone with basic git skills and I see it introduce a lot of friction 
for some people's first merge requests.

3. The merge-stable-to-master workflow involves fixing trivial merge 
conflicts every time the version changes in CMakeLists.txt. It's easy to 
fix, but annoying to have to keep doing it over and over again. The 
cherry-pick workflow doesn't have this issue.

Nate



On 12/3/21 10:55, Kai Uwe Broulik wrote:
> Hi everyone,
> 
> as part of the GitLab transition in Plasma we changed our commit 
> strategy from committing to stable and merging to master to committing 
> to master and cherry-picking to stable. Reason being that it's a lot 
> more convenient to do from GitLab's UI. I can merge and cherry-pick all 
> from the web UI.
> 
> However, other projects, such as most of KDE Gear, continues using 
> merging, which makes the experience inconsistent and tedious. Fully 
> retargeting a branch doesn't seem possible from the UI and not sure if 
> you can merge up there either.
> 
> What's keeping us from changing the strategy for the rest of KDE, too?
> 
> Cheers
> Kai Uwe