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
