On 24/08/20 21:55, Albert Astals Cid wrote: > El dilluns, 24 d’agost de 2020, a les 0:39:17 CEST, Elvis Angelaccio va > escriure: >> >> 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 disagree for it to per project, it has to be a global policy, otherwise > contributing gets more complicated, since I have to remember for each project > if they want bugfix patches to master or to stable. > > Or at least it has to be the same for all the release service projects, > because otherwise it'll break my brain when doing the branching for new > releases. Right now i know that we always commit to stable and then merge to > master, but since people are lazy i know i have to run a merge from stable to > master before branch for all projects, if we let this decision to be per > project, what do I do? > >> 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. > > Why would it be double the work?
I was mainly referring to the amount of work for tests. The git part is trivial either way indeed. > > Now: > * Press the merge button in the gitlab UI > * git fetch && git checkout master && git pull --rebase && git merge > origin/stable/branch > > After: > * Press the merge button in the gitlab UI > * git fetch && git checkout stable && git pull --rebase && git cherry-pick > origin/master > > Seems the same amount of work to me (if there's no conflicts) Now: * Test the fix on stable * Push to stable * Merge stable to master After: * Test the fix on master * Push to master * Test the fix on stable * Cherry-pick to stable In the second model I need to test twice because I can't change the stable branch without testing. > > Cheers, > Albert Cheers, Elvis
