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/[email protected]/
