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

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

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).

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.

  (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.