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

Reply via email to