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
