Git merge workflow: reverse it?

[Albert Astals Cid]

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? 

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)

Cheers,
  Albert

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