<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>