On Tue, May 10, 2022 at 9:36 AM Kai Uwe Broulik <k...@privat.broulik.de> wrote: > > Hi, > > can we get an update on this? > > Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and > frustrating when some projects use cherry-pick (e.g. Kate) and some > don't (e.g. Dolphin). > > I don't really mind what the outcome is but I need it to be consistent > and predictable where to target my MRs, at least for every domain > (Plasma, Gear, ..). > > Cheers > Kai Uwe > > PS: Since I can never remember: it's git rebase --onto newbase oldbase > branch > > Am 29.07.20 um 14:01 schrieb Bhushan Shah: > > Hello everyone! > > > > At plasma, we are experimenting with new workflow regarding how bugfixes > > are put on the stable branch [1]. > > > > # Previous workflow > > > > - Current workflow is that we commit to stable branch and then merge it > > upwords until master branch > > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > > master > > > > # Current workflow > > > > - Proposed workflow is to instead commit all changes in master, and > > cherry-pick related changes in the stable branch as needed > > - We had been using this workflow for about 1 month now and I'd say it > > is working nicely for us. > > > > # Why? > > > > We occasionally hit several issues with previous workflow, > > > > - Merge conflicts when merging changes upwords > > - Changes which are valid only for stable branch needs to be reverted in > > master branches. So you end-up with, stable-fix, revert of stable fix > > and then different fix and overall weird history. > > - Accidential merges from the master branch to stable branch which > > needs to be force-resetted. > > - It's worth noting that Qt also recently changed to merge to dev, > > cherry-pick backwards. > > - This also allows for workflows where we want to commit some bugfix in > > the master branch for few days/weeks and if it works fine in general > > testing then, cherry-pick it in stable branches. > > > > Proposal is to probably adapt this policy kde-wise if people feel that > > advantages are worth it. > > > > Thanks > > > > [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html > >
After having worked with using the Plasma workflow of cherry-picking into stable (and especially since switching to gitlab) I don't really see ourselves using something else. As far as I remember it's worked great, it's super easy to implement and I don't really remember things going worse but it sure is simpler to track as a developer (and maintainer). Aleix