All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Dave Airlie" <airlied@gmail.com>
Cc: "Rodrigo Vivi" <rodrigo.vivi@intel.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, 04 Nov 2026 12:08:08 +0100	[thread overview]
Message-ID: <DMMDNQ0GD6AP.6HPRG6JWUEYQ@kernel.org> (raw)
In-Reply-To: <CAPM=9tzu6MYQ-Y0iYK=2PLiM5=1BsEN+Q5WnmYh=hkKnLJ4b1Q@mail.gmail.com>

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.

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 11:08 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 [this message]
2026-11-04 17:44                           ` Rodrigo Vivi
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=DMMDNQ0GD6AP.6HPRG6JWUEYQ@kernel.org \
    --to=dakr@kernel.org \
    --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=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=rodrigo.vivi@intel.com \
    --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.