Gitlab merge workflow: reverse it?

[Noah Davis]

I'm in favor of merging to master first. It's just easier for me to
work that way because the cherry picking is something I can just add
on top of my normal git workflow instead of having to remember a
different git workflow for situations where we may want to patch a
stable branch.

On Thu, Jun 25, 2020 at 10:46 AM 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
>
> # 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
>
> 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?
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D