From kde-devel  Mon Dec 06 13:57:24 2021
From: David Jarvie <djarvie () kde ! org>
Date: Mon, 06 Dec 2021 13:57:24 +0000
To: kde-devel
Subject: Re: Merge stable to master vs cherry-picking
Message-Id: <6CBB8BB6-817C-46BF-917F-EBE5BB88A4E0 () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-devel&m=163879903600484



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

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

> On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik <kde@privat=2Ebroulik=2Ed=
e> 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=2E Reason being that it's a lot
> > more convenient to do from GitLab's UI=2E I can merge and cherry-pick =
all
> > from the web UI=2E
> >
> > However, other projects, such as most of KDE Gear, continues using
> > merging, which makes the experience inconsistent and tedious=2E Fully
> > retargeting a branch doesn't seem possible from the UI and not sure if
> > you can merge up there either=2E
> >
> > What's keeping us from changing the strategy for the rest of KDE, too?
> >
> > Cheers
> > Kai Uwe
>=20

--
David Jarvie
KAlarm author, KDE developer