On Wed, Dec 8, 2021 at 12:08 PM Sandro Knauß <skna...@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
