Git merge workflow: reverse it?

[Johan Ouwerkerk]

On Mon, Aug 3, 2020 at 11:50 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va escriure:
> > At plasma, we are experimenting with new workflow regarding how bugfixes
> > are put on the stable branch [1].
> >
> > # 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.
> >
>
> The conflicts are still going to be there, if your change has conflicts going up, it'll have conflicts going down.
>

I guess it's mostly about who is doing the merging and committing in
this: the hopefully more seasoned people who know the code well
because they've been maintaining it for a while or the casual
contributor who might not be fully aware of what master might have
moved away from that is still in stable (or the reverse).

It might also be slightly easier to realise that it turns out you have
to backport a bit more, than it is to future proof your code coming
from the deep past to minimise the merge conflicts, as it were.

>
> One improvement I think you didn't mention is:
>  - "Non-core" people don't know what's the stable branch. I see that in Okular, most drive-by Merge Requests are against master, because that's the easy thing to do, for a "newbie" it's hard to figure out if something should go to the stable branch or not (is it a bugfix? a feature?), and if so, which is the stable branch if there's one, etc.
>

I think this one thing alone is the main reason to just do it. People
who maintain stable branches know what they signed up for and
generally have a pretty good understanding of what they're doing. Even
seasoned KDE contributors are going to find a workflow with a single
target branch (always master) to be slightly easier to remember than
"whatever the stable branch happens to be".

> > Proposal is to probably adapt this policy kde-wise if people feel that
> > advantages are worth it.

I'd lean towards +1

Regards,

- Johan