Git merge workflow: reverse it?

[boud at valdyas.org]

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) and cherry-pick or port 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.

Boudewijn