All of lore.kernel.org
 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: 19+ 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-13 12:36       ` Mark Brown
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
2026-08-13 11:57       ` Krzysztof Kozlowski

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