Git merge workflow: reverse it?

[Elvis Angelaccio]

On 24/08/20 22:07, boud at valdyas.org wrote:
> On 2020-08-24 21:55, Albert Astals Cid wrote:
> 
>> 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.
> 
> The current "global policy" isn't global already, of course. I'd never
> even heard of it. And if I had, I would never have accepted it, since
> it's bad practice. You don't merge stable branches into unstable, or the
> other way around. You keep track of your patches (more or less
> succesfully)

I like to use git for that because it's designed for this task. :)

> and cherry-pick or port them.

Or you can merge stable to master and be sure you won't forget anything.
Of course if master changed a lot you can't (easily) do that. But we
have a lot of repos that don't change very often and merging stable to
master works very well with them.

> 
> It's the maintainer's job to keep track of that, or make sure the other
> team members know what they should do.
> 
>> 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?
> 
> You don't do anything; if the maintainers of those projects cannot
> manage their patch workflow, well, shucks. And if you're the maintainer,
> then you need to keep track of all that.

The problem is we don't always have a maintainer. A lot of apps are
community-maintained and if we wouldn't merge stable to master before a
new release we would reintroduce fixed bugs quite often.

> 
> Boudewijn

Cheers,
Elvis