On 29/07/20 14:01, Bhushan Shah wrote: > Hello everyone! Hi Bhushan > > 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. IMHO the workflow choice should be left to each project. I can see why you may want to use it in Plasma, but for the apps I maintain it would probably double the work for no practical gain.
I'd be ok with a global policy "if unsure always send a MR against master" (newcomers already do that anyway), but then it should be up to the maintainer to choose how to handle the MR. > > Thanks > > [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html > Cheers, Elvis