Merge stable to master vs cherry-picking

[Slawek Kaplonski]

Dzień dobry,

On środa, 8 grudnia 2021 00:01:18 CET Albert Astals Cid wrote:
> El dimarts, 7 de desembre de 2021, a les 23:20:19 (CET), Slawek Kaplonski va 
escriure:
> > Hi,
> > 
> > On poniedziałek, 6 grudnia 2021 19:20:20 CET Albert Astals Cid wrote:
> > > 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.
> > 
> > Maybe I'm missing something but in case which You described, You will 
still
> > need to build all that from master branch to propose patch from stable to
> > master. Otherwise how You will know if patch needs to be in master or 
maybe
> > it's already fixed in other way there?
> 
> That's the maintainer problem/responsibility (i.e. not mine)

Ok, thx. I was just curious about it:)
I'm new in KDE development so I don't know its processes well yet.
I mostly contribute to the OpenStack projects where we always do patches for 
master first and then cherry-pick them to stable branches. But we are using 
Gerrit there so the whole workflow is slightly different :)

> 
> Cheers,
>   Albert
> 
> > > Cheers,
> > > 
> > >   Albert
> > >   
> > > > HS
> > > > 
> > > > On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik <kde at 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



-- 
Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20211208/8424bc0b/attachment.sig>