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 ={ What I'll do from now on is trying to check all hashes that match a commit, so I can add more than one fixes tag if that makes sense. At least, this way I can prevent missing fixes in stable like this patch heh @Greg, can you pick this one? Thanks! Cheers, Guilherme