On Thu, 05 Nov 2026, "Danilo Krummrich" <[email protected]> wrote: > 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.
Fair enough. > 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). Yeah, this part is really not great. Throwing around ideas here, thanks for taking the time to debunk. > 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]/ At a glance, I think the *feature* sounds good. But I think we're all just going to forget to add --final. The reason we have dim in the first place is to make us do stuff the same way, every time, and not forget stuff. When we screwed up, we addressed it in dim to not screw up again. Not everything can be easily automated or enforced. Perhaps you've noticed dim asks for confirmation when you're trying to push merges or more than ten patches. Usually it's something committers shouldn't do, but maintainers occasionally need to. Anyway, how about just *prompting* "Is this expected to be the final pull request for the development cycle?", and if yes, update drm-*-next-fixes while at it, and have the automation handle the rest. You should be able to do another final PR if something urgent comes up, and it'll be just fine. Also, if we are able to make dim more -rc cycle aware, the above could also start asking the question at -rc3 or -rc4 or so. BR, Jani. -- Jani Nikula, Intel
