Re: [RFC] linux-next: replace the DRM trees with a single drm-for-linux-next

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Nov 5, 2026 at 10:52 PM CET, Rodrigo Vivi wrote:
> On Wed, Nov 04, 2026 at 11:35:10PM +0100, Danilo Krummrich wrote:
>> On Wed Nov 4, 2026 at 6:44 PM CET, Rodrigo Vivi wrote:
>> > On Wed, Nov 04, 2026 at 12:08:08PM +0100, Danilo Krummrich wrote:
>> >> On Wed Nov 4, 2026 at 4:29 AM CET, Dave Airlie wrote:
>> >> > Yes this is the thing I like, while I like maintainers having freedom,
>> >> > relying on them to do something manually every release at the same
>> >> > time doesn't seem to scale so well.
>> >> 
>> >> I think maintainers have to do something manually every release in both cases.
>> >> 
>> >> The difference is between "everyone has to do it at the exact cutoff day" vs.
>> >> "everyone has to fast-forward their -next-fixes branch" (which to be fair has to
>> >> be done in both cases).
>> >> 
>> >> For the former, a tree that closes before the global cutoff can still leak
>> >> following-cycle work into linux-next.
>> >
>> > On that I already agreed that we should move the blackout from -rc6 to -rc5.
>> > So, the only thing that every maintainer needs to ensure is to prepare,
>> > at least, one PR after -rc5 and we won't have absolutely any leak.
>> >
>> > And I believe we are all already doing this anyway, so again, there won't be any
>> > special thing that maintainers would need to do to ensure correctness.
>> 
>> It doesn't change the fundamental problem if we define the global cutoff sooner
>> or later.
>> 
>> To preserve both properties, each tree's transition would have to coincide with
>> the global cutoff., otherwise it can happen that either stuff leaks into
>> linux-next that doesn't belong there (tree state updated before cutoff), or
>> you're not getting linux-next exposure in the first place (tree state updated
>> after cutoff).
>> 
>> Making the cutoff day sooner makes it much more unlikely to leak stuff into
>> linux-next, as closing a tree before -rc5 would be pretty odd.
>> 
>> But that trades the leakage risk for patches added after -rc5 losing linux-next
>> exposure until they reach drm-next. That may be preferable, but it still loses
>> intended linux-next coverage.
>> 
>> In a normal cycle this would mean that trees collect up to a full week of
>> patches without them seeing linux-next, which is a concern for me as well.
>> 
>> More generally it remains that correctness is based on a timing promise about
>> the tree state rather than the tree state itself (which is the actual source of
>> truth).
>
> The current way is already a 'timing promise'. Multiple promises in a matter of
> fact. promise that you will send the PR around -rc5, -rc6 anyway + promise that
> you will update your -next-fixes so the current fragile blackout check works.

Of course one still wants to send the final PR somewhen around -rc5/-rc6, but
there's no exact point of time where the corresponding tree management has to be
done in order for the correct thing to happen for linux-next.

I don't agree that the the update of -next-fixes is fragile. It has to be fast
forwarded to -next anyway with the cutoff, as otherwise people can't apply fixes
for what's staged for the merge window anymore.

If we'd cut off but not update -next-fixes accordingly, it's an invitation for
committers to keep pushing to -next kicking of the cherry-picks.

I also think this works very well for drm-misc (and drm-rust).

>> I don't see why we would want to make this kind of compromise where we prevent
>> intended linux-next exposure for up to a week, while the existing per-tree
>> selection logic in dim we have today can preserve both properties:
>> following-cycle work stays out of linux-next, and work for the upcoming merge
>> window gets linux-next exposure before entering drm-next.
>> 
>> To me a fixed global cutoff in tip comes down to either one of the two:
>> 
>>   (1) Make a compromise where e.g. patches that belong in linux-next get up to a
>>       week delayed exposure.
>
> I really fail to see how this is a issue...

Because it means less exposure to linux-next overall and less exposure where it
actually matters, at the end of the cycle.

It also means that if something breaks in linux-next during this period the only
way to fix it is to 1. send another -next PR, 2. wait until the tree closes and
push the fix to -next-fixes, 3. close the tree immediately and push the fix to
-next-fixes.

> But anyway, as I told, please provide the patches to dim for the unified tree
> with a more reliable way to guarantee our promises and let's take from there.

Sure, I'm happy to look into this.

>> 
>>   (2) Require each tree's transition to following-cycle work to coincide with
>>       the global cutoff, in *addition* to managing its branches correctly.
>> 
>> >> I.e. the global switch is automatic, but doesn't ensure correctness by itself.
>> >> In order to be correct, maintainers have to do something manually.
>> >> 
>> >> So eventually it comes down to whether doing the correct thing derives from an
>> >> explicit operation (i.e. fast-forward -next-fixes, or just add the --final
>> >> helper), or an implicit commitment to push and tag branches on a specific day.
>> >> 
>> >> I think it is better to derive the tree status from its actual state rather than
>> >> a promise about that state at a specified cutoff day.
>> >> 
>> >> > If we can't have the tool enforce what we send to -next after -rc6
>> >> > then it's going to have gaps.
>> >> 
>> >> I don't think either option can enforce correctness. The difference is that one
>> >> approach relies on a timing promise about the tree state, while the other uses
>> >> the tree state itself to make the decision.
>>