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 --]
next prev 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