"You keep track of your patches (more or less succesfully) and cherry-pick or port them."
This sums up what I do with kdiff3. In fact right now trying to merge between stable and master or the other way around would be a nightmare project due to heavy refactoring. On Mon, Aug 24, 2020, 4:07 PM <[email protected]> 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) 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. > > Boudewij >
