Merge stable to master vs cherry-picking

[Ben Cooksley]

On Wed, Dec 8, 2021 at 12:08 PM Sandro Knauß <sknauss at 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, etc)
>
> > > 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 from
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20211208/9f661366/attachment-0001.htm>