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
