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

Reply via email to