Linux Kernel Summit discussions
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Mark Brown <broonie@kernel.org>,
	ksummit@lists.linux.dev,  linux-next@vger.kernel.org
Subject: Re: [MAINTAINERS SUMMIT] Any feedback for -next?
Date: Thu, 13 Aug 2026 11:59:19 +0200	[thread overview]
Message-ID: <an2T29K_NNR2vrhq@orome> (raw)
In-Reply-To: <anxaYg9XL7nD9w40@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Wed, Aug 12, 2026 at 04:42:21AM -0700, Breno Leitao wrote:
> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > Any other ideas?
> 
> I'm new to this area, so please forgive what might be a silly
> question: would it make sense for maintainers' -next trees to keep
> a stable git history?
> 
> Some maintainer trees are already stable and append-only, which
> gives linux-next users/testers stable commits to point to, instead
> of ephemeral commits that can disappear later due to history
> rewrites.
> 
> Would getting rid of these ephemeral commits make linux-next easier
> to work with?

I think this is a problem that we can easily address using tools. next
already has scripts to detect these issues and I think perhaps we can
provide a variant of those in a way that would allow people to set them
up in their tree as maybe git hooks so they automatically get run on
pre-push or something.

On the trees that I maintain, I do that using a set of scripts that I've
found useful. I know many other maintainers do their own versions of the
same tests and I suspect the maintainers that don't are in the category
of not knowing that they should be checking for these thing or just
don't know how or lack the time/motivation to set this up. If we can
take some of the lessons learned from linux-next and distill it into
some scripts and maybe documentation, I think we can catch the vast
majority of these cases, and the rest we can catch in linux-next, or we
can ask Linus to run this set of sanity checks on merges as a last
resort.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2026-08-13  9:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 16:54 [MAINTAINERS SUMMIT] Any feedback for -next? Mark Brown
2026-08-11 19:31 ` Geert Uytterhoeven
2026-08-12 11:19 ` Uwe Kleine-König
2026-08-12 16:37   ` Mark Brown
2026-08-12 16:45     ` Sasha Levin
2026-08-12 17:02       ` Mark Brown
2026-08-13  7:31     ` Geert Uytterhoeven
2026-08-13  9:19       ` Uwe Kleine-König
2026-08-12 11:42 ` Breno Leitao
2026-08-12 15:27   ` Steven Rostedt
2026-08-12 15:59     ` Lee Jones
2026-08-12 17:10       ` Guenter Roeck
2026-08-12 17:14         ` Arnaldo Carvalho de Melo
2026-08-12 17:37           ` Guenter Roeck
2026-08-12 19:40             ` Arnaldo Carvalho de Melo
2026-08-13  9:59   ` Thierry Reding [this message]
2026-08-13 11:25     ` Mark Brown

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=an2T29K_NNR2vrhq@orome \
    --to=thierry.reding@kernel.org \
    --cc=broonie@kernel.org \
    --cc=ksummit@lists.linux.dev \
    --cc=leitao@debian.org \
    --cc=linux-next@vger.kernel.org \
    /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