From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Dave Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Matthew Brost" <matthew.brost@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org,
"Mark Brown" <broonie@kernel.org>,
linux-next@vger.kernel.org
Subject: Re: [RFC] linux-next: replace the DRM trees with a single drm-for-linux-next
Date: Mon, 2 Nov 2026 14:20:49 -0500 [thread overview]
Message-ID: <aujikV14tF6K1Xqw@intel.com> (raw)
In-Reply-To: <DMKY979I29AF.BS1DF5YAZMOY@kernel.org>
On Mon, Nov 02, 2026 at 07:51:13PM +0100, Danilo Krummrich wrote:
> >
> > The unified branch is rebuilt by dim together with drm-tip. It has all the DRM
> > -fixes, drm-next, -next-fixes and driver -next branches merged, with
> > the conflicts between them already resolved on our side. From -rc6
> > until -rc1 (per Linus' tree) the driver -next branches are left out, so
> > nothing for the following merge window lands early.
>
> Seems reasonable; I assume the logic for individual trees would remain? I.e.
> -next goes into tip/for-linux-next until -next-fixes is fast forwarded? IOW,
> trees keep control over when exactly -next closes for the upcoming merge window?
Well, the flows of -next, -next-fixes, -fixes keeps the same. No change in that
or in our PR flows.
As for the mechanics of the closes, I'd say that for drm-xe and drm-intel, there's
absolutely no change. We consider our closure when send the last PR on that cycle.
But perhaps this was anyway a gap on our side?! to ensure that our -next-fixes are
in sync with our last PR?! (plus the gap of xe which was feeding with drm-xe-next
directly).
For the rust and others, the honest answer is: "not exactly..."
not exactly... The per-tree check goes away and there's one global rule:
the driver -next branches are left out from Linus' -rc6 until -rc1.
But this is the cutoff the drm-rust docs already describe and used by everyone
anyway.
So, the maintainers are still in control on when their -next is closed. But that
is their last PR. around -rc5/-rc6. And if they need extra PRs after that, it
is also fine, because drm/drm-next is still feeding this unified for-next.
So, whatever Dave and Sima accept during the blackout will be covered. Regardless
the state of your -next-fixes.
And, in any case, -next-fixes is always included, even during the freeze.
IOW, when you fast-forward drm-rust-next-fixes at your cutoff, that content stays
in linux-next whenever you do it. The only difference is that drm-rust-next
itself stops at -rc6, not when you fast-forward.
Thanks,
Rodrigo.
next prev parent reply other threads:[~2026-11-02 19:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 18:41 [RFC] linux-next: replace the DRM trees with a single drm-for-linux-next Rodrigo Vivi
2026-11-02 18:51 ` Danilo Krummrich
2026-11-02 19:20 ` Rodrigo Vivi [this message]
2026-11-02 20:01 ` Danilo Krummrich
2026-11-03 2:05 ` Dave Airlie
2026-11-03 19:32 ` Danilo Krummrich
2026-11-03 20:33 ` Rodrigo Vivi
2026-11-03 21:04 ` Danilo Krummrich
2026-11-03 21:19 ` Alex Deucher
2026-11-03 22:48 ` Rodrigo Vivi
2026-11-03 23:01 ` Danilo Krummrich
2026-11-04 2:37 ` Rodrigo Vivi
2026-11-04 3:29 ` Dave Airlie
2026-11-04 11:08 ` Danilo Krummrich
2026-11-04 17:44 ` Rodrigo Vivi
2026-11-04 22:35 ` Danilo Krummrich
2026-11-05 21:52 ` Rodrigo Vivi
2026-11-05 23:27 ` Danilo Krummrich
2026-11-05 13:44 ` Jani Nikula
2026-11-05 21:08 ` Danilo Krummrich
2026-11-06 11:08 ` Jani Nikula
2026-11-06 12:10 ` Mark Brown
2026-11-06 16:37 ` Danilo Krummrich
2026-11-03 22:39 ` Rodrigo Vivi
2026-11-02 18:58 ` Mark Brown
2026-11-02 23:07 ` Alex Deucher
2026-11-03 20:35 ` Rodrigo Vivi
2026-11-03 21:24 ` Alex Deucher
2026-11-04 5:49 ` Thorsten Leemhuis
2026-11-04 11:48 ` Mark Brown
2026-11-04 12:46 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aujikV14tF6K1Xqw@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=aliceryhl@google.com \
--cc=broonie@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-next@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox