[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: Albert Astals Cid <aacid () kde ! org>
Date: 2021-12-06 18:20:20
Message-ID: 1709768.VLH7GnMWUR () xps
[Download RAW message or body]
El dilluns, 6 de desembre de 2021, a les 7:07:50 (CET), Harald Sitter va escriure:
> I'm all for cherry picking. It's both easier and makes sure fixes are
> actually available in master.
I don't agree that cherry-picking is easier.
Example: I want to fix a bug in kmail.
Fixing it in master means i have to build a zillion of repositories before even \
trying to start fixing the bug, it may also happen that once I built master i can't \
reproduce the bug because master has been fixed for various reasons (re-architecture, \
fixed the bug and forgot to cherry-pick, etc)
Fixing it in the stable branch is much easier, just build the kmail repo and fix the \
bug.
Cheers,
Albert
>
> HS
>
> 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
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic