Git merge workflow: reverse it?

[Elvis Angelaccio]

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