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
