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 2:44 PM CET, Jani Nikula wrote:
> The main downside is the delay between merging in a driver tree and
> hitting linux-next. But we could also decide to mandate more regular
> pull request to drm-next, maybe weekly, especially for the drivers with
> more traffic. This will mean lots more pull requests, but it's really
> not a bad thing to keep them smaller.

I was already concerned about losing up to a week's linux-next exposure with the
proposed global cutoff at -rc5 [1]. This approach would extend that delay
throughout the cycle.

Even with weekly PRs, changes could wait up to a week before reaching
linux-next. They would also only get that exposure after being merged into
drm-next, whereas I'd like them to receive linux-next testing before that merge.

I don't think that such a compromise is acceptable: If a tree breaks linux-next
it would mean that linux-next is broken until the next PR hits drm-next (and not
only until it is fixed in the tree causing the issue).

I don't want to sound like a broken record (sorry if I already do :), but I
still think the

	git merge-base --is-ancestor $remote/$linux_next_fixes $remote/$linux_fixes

switch we already have in dim seems like the best fit. It already does exactly
what we (and linux-next) need and is accurate: it preserves direct linux-next
coverage and bases the selection on the actual tree state. And with the proposed
git request-pull --final option it is very maintainer friendly.

[1] https://lore.kernel.org/all/DMMS9R5JJ4ME.TBIB1TNLB3IP@kernel.org/