Merge stable to master vs cherry-picking

Alexander Potashev aspotashev at gmail.com
Fri Dec 3 22:16:25 GMT 2021


Hi everyone,

+my 2 cents: I prefer merging from stable to master because it doesn't
require me to know which commits should be ported.

On Fri, Dec 3, 2021 at 9:20 PM Nate Graham <nate at kde.org> wrote:
>
> 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



-- 
Alexander Potashev


More information about the kde-devel mailing list