[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Merge stable to master vs cherry-picking
From:       David Jarvie <djarvie () kde ! org>
Date:       2021-12-06 13:57:24
Message-ID: 6CBB8BB6-817C-46BF-917F-EBE5BB88A4E0 () kde ! org
[Download RAW message or body]



On 6 December 2021 06:07:50 GMT, Harald Sitter <sitter@kde.org> wrote:
> I'm all for cherry picking. It's both easier and makes sure fixes are
> actually available in master.

I like cherry picking since it tends to be more straightforward than merging, but \
there's always the danger that someone might forget to cherry pick a fix. Merging \
ensures that fixes will always be made available in master, without relying on people \
always remembering to do the right thing. So as I see it, merging is the only safe \
way to ensure that fixes are applied to both branches.

> On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik <kde@privat.broulik.de> 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
> 

--
David Jarvie
KAlarm author, KDE developer


[prev in list] [next in list] [prev in thread] [next in thread]