Gitlab merge workflow: reverse it?

[David Edmundson]

On Thu, Jun 25, 2020 at 3:46 PM Bhushan Shah <bshah at mykolab.com> wrote:

> Hello everyone!
>
> This is a proposal to change our workflow regarding release branches and
> our merge workflow,
>
> # Current 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
>
> # Proposed workflow
>
> - Proposed workflow is to instead commit all changes in master, and
>   cherry-pick related changes in the stable branch as needed
>
>
Gitlab supposedly has a magic button for it just after a commit has landed
in master.
https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html

Though I don't know how to trigger that in our UI.


> # Why?
>
> We occasionally hit several issues with current workflow,
>
> - Merge conflicts when merging changes upwords
> - Changes which are valid only for stable branch needs to be reverted in
>   master branches
> - Accidential merges from the master branch to stable branch which needs
>   to be force-pushed
>
> It's worth noting that Qt also recently changed to merge to dev,
cherry-pick backwards.
In principle I completely agree.

I have a few fears, which I hope are all addressable.

  - we need some reference to the real commit.

Qt adds
"    (cherry picked from commit 6de0287d7c3aa4251fe6eb4f970d73ce11cf07fc)"
to the commit message automagically somehow in their workflow.

  - without making people commit locally into stable, could it encourage
people to not test as much?


> For now I am proposing this change only for Plasma repositories if we
> like it, we can propose this workflow for rest of KDE repositories, but
> that needs discussions in kde-devel/kde-core-devel separately.
>
> Thoughts?
>

I like consistency across KDE, otherwise it's very difficult for people who
contribute in N places.
We should at least email before we change, though we can still discuss
things here first.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200625/75fe0431/attachment.htm>