[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: Ben Cooksley <bcooksley () kde ! org>
Date: 2021-12-08 6:44:32
Message-ID: CA+XidOGo=bvQFB64CsxmmV0zmR7s6qpx2XPrTVfAKEM7xc-52Q () mail ! gmail ! com
[Download RAW message or body]
On Wed, Dec 8, 2021 at 12:08 PM Sandro Knau=C3=9F <sknauss@kde.org> wrote:
> Hi,
>
> > > 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, et=
c)
>
> > > Fixing it in the stable branch is much easier, just build the kmail
> repo
> > > and fix the bug.
>
> I fully agree: merge stable is much clearer and easier.
>
> > 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?
>
> Well for kdepim master means: I need the newest KDE Frameworks available,
> my
> distro is not that fast shipping them every month. Than I need to build
> the
> complete pimstack, as you cannot mix different version. This is a lot of
> work
> just to fix one bug I know that isn't addressed ;) And the bugs are nasty
> when
> you only see them once in while, so you need to run your fix for several
> days
> to make sure something is fixed. That's why it is that hard to run it fro=
m
> master branch.
> I think that the entrace barrier is higher, when we only have
> cherry-picking
> and that means that even less people are able to fix kdepim.
> I think especially for newcommers and drive-by committers it is much
> easier to
> be able to just rebuilt one repo instead of a complete stack.
>
This is why I have been pushing for people to use @stable in their
.kde-ci.yml files - even for the 'master' branch.
It is much simpler for people if you can use stable/released dependencies
when conducting development.
> My gut feeling is that git is smarter when you merge than cherry-pick. If
> there are renames or code refactoring happing in master than merge
> strategy is
> more reliable. At least I get often very small issues when merging stable=
.
>
> One big argument against cherry-picking is that you are never know if
> everything is inside master because the branches have differnt commits.
> When
> merging stable to master, than you can be sure that everything changed on
> stable is in master.
>
> Cheers,
>
> sandro
>
Cheers,
Ben
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec \
8, 2021 at 12:08 PM Sandro Knauß <<a \
href="mailto:sknauss@kde.org">sknauss@kde.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi,<br> <br>
> > Fixing it in master means i have to build a zillion of repositories \
before<br> > > even trying to start fixing the bug, it may also happen that \
once I built<br> > > master i can't reproduce the bug because master has \
been fixed for various<br> > > reasons (re-architecture, fixed the bug and \
forgot to cherry-pick, etc)<br> <br>
> > Fixing it in the stable branch is much easier, just build the kmail \
repo<br> > > and fix the bug.<br>
<br>
I fully agree: merge stable is much clearer and easier.<br>
<br>
> Maybe I'm missing something but in case which You described, You will \
still<br> > need to build all that from master branch to propose patch from stable \
to<br> > master. Otherwise how You will know if patch needs to be in master or \
maybe<br> > it's already fixed in other way there?<br>
<br>
Well for kdepim master means: I need the newest KDE Frameworks available, my <br>
distro is not that fast shipping them every month. Than I need to build the <br>
complete pimstack, as you cannot mix different version. This is a lot of work <br>
just to fix one bug I know that isn't addressed ;) And the bugs are nasty when \
<br> you only see them once in while, so you need to run your fix for several days \
<br> to make sure something is fixed. That's why it is that hard to run it from \
<br> master branch. <br>
I think that the entrace barrier is higher, when we only have cherry-picking <br>
and that means that even less people are able to fix kdepim.<br>
I think especially for newcommers and drive-by committers it is much easier to <br>
be able to just rebuilt one repo instead of a complete \
stack.<br></blockquote><div><br></div><div>This is why I have been pushing for people \
to use @stable in their .kde-ci.yml files - even for the 'master' \
branch.</div><div>It is much simpler for people if you can use stable/released \
dependencies when conducting development.<br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
My gut feeling is that git is smarter when you merge than cherry-pick. If <br>
there are renames or code refactoring happing in master than merge strategy is <br>
more reliable. At least I get often very small issues when merging stable.<br>
<br>
One big argument against cherry-picking is that you are never know if <br>
everything is inside master because the branches have differnt commits. When <br>
merging stable to master, than you can be sure that everything changed on <br>
stable is in master.<br>
<br>
Cheers,<br>
<br>
sandro<br></blockquote><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic