On 24/08/20 22:07, b...@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
