On Thu, Apr 20, 2023 at 09:36:28AM -0300, Guilherme G. Piccoli wrote: > On 19/04/2023 17:04, Deucher, Alexander wrote: > > [...] > >> So, let me check if I understood properly: there are 2 trees (-fixes and > >> -next), > >> and the problem is that their merge onto mainline happens apart and there > >> are kind of duplicate commits, that were first merged on -fixes, then "re- > >> merged" on -next, right? > >> > > > > Each subsystem works on new features, then when the merge window opens, > > Linus pulls them into mainline. At that point, mainline goes into RCs and > > then mainline is bug fixes only. Meanwhile in parallel, each subsystem is > > working on new feature development for the next merge window (subsystem > > -next trees). The trees tend to lag behind mainline a bit. Most > > developers focus on them in support of upcoming features. They are usually > > also where bugs are fixed. If a bug is fixed in the -next tree, what's the > > best way to get it into mainline? I guess ideally it would be fixed in > > mainline and them mainline would be merged into everyone's -next branch, > > but that's not always practical. Often times new features depend on bug > > fixes and then you'd end up stalling new development waiting for a back > > merge, or you'd have to rebase your -next branches regularly so that they > > would shed any patches in mainline which is not great either. We try and > > cherry-pick -x when we can to show the relationship. > > > >> Would be possible to clean the -next tree right before the merge, using > >> some script to find commits there that are going to be merged but are > >> already present? Then you'd have a -next-to-merge tree that is clean and > >> doesn't present dups, avoiding this. > > > > There's no real way to clean it without rewriting history. You'd basically > > need to do regular backmerges and rebases of the -next trees. Also then > > what do you do if you already have a feature in -next (say Dave or Daniel > > have already pulled in my latest amdgpu PR for -next) and you realize that > > one of those patches is an important bug fix for mainline? If the drm > > -next tree rebased then all of the other drm driver trees that feed into it > > would need to rebase as well otherwise they'd have stale history. > > > > You also have the case of a fix in -next needing to land in mainline, but > > due to differences in the trees, it needs backporting to apply properly. > > > >> > >> Disclaimer: I'm not a maintainer, maybe there are smart ways of doing that > >> or > >> perhaps my suggestion is silly and unfeasible heh But seems likely that > >> other > >> maintainers face this problem as well and came up with some solution - > >> avoiding the dups would be a good thing, IMO, if possible. > > > > > > No worries. I agree. I haven't seen anything so far that really addresses > > handles this effectively. > > > > Alex > > Thanks a bunch Alex, I appreciate your time detailing the issue, which > seems...quite complex and annoying, indeed ={
And it drives me crazy, I hate seeing drm patches show up in my stable queue and I put them at the end of the list for this very reason. I've complained about it for years, but oh well... > @Greg, can you pick this one? Thanks! Which "one" are you referring to here? confused, greg k-h