All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Dave Airlie" <airlied@gmail.com>,
	"Alex Deucher" <alexdeucher@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: Wed, 4 Nov 2026 12:44:43 -0500	[thread overview]
Message-ID: <autvCxZuSCxFjtgr@intel.com> (raw)
In-Reply-To: <DMMDNQ0GD6AP.6HPRG6JWUEYQ@kernel.org>

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.

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

  reply	other threads:[~2026-11-04 17:44 UTC|newest]

Thread overview: 23+ 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
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 [this message]
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=autvCxZuSCxFjtgr@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.