ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Sasha Levin <sashal@kernel.org>, Kees Cook <kees@kernel.org>,
	ksummit@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull requests
Date: Wed, 23 Oct 2024 19:51:04 -0700	[thread overview]
Message-ID: <d8087943-0a9c-4e1e-8873-48a15e1311dc@paulmck-laptop> (raw)
In-Reply-To: <bf42489f-4a86-4717-b367-d8be877b3036@sirena.org.uk>

On Wed, Oct 23, 2024 at 10:24:29PM +0100, Mark Brown wrote:
> On Wed, Oct 23, 2024 at 11:06:59AM -0700, Linus Torvalds wrote:
> 
> > And yes, I know some people do functional testing on linux-next
> > already. The message at the maintainer summit was a bit mixed with
> > some people saying linux-next tends to work even for that, others
> > saying it's often too broken to be useful.
> 
> It very much depends on what you're trying to get out of the testing -
> -next does work well most of the time, but it will absolutely just blow
> up catastrophically on you from time time to time so you have to be
> prepared to cope with loosing some or all of your coverage sometimes.
> Usually anything major gets fixed fairly promptly, but sometimes you'll
> be missing coverage for extended periods especially if it's something
> like a more niche platform that's been broken or there's some problem
> getting people to actually apply the fixes.  Submaintainer trees that
> people don't want to add to -next can be an issue too.
> 
> You're also going to run into issues that are nothing to do with
> whatever you're actually working on yourself and need to consider what
> you're covering based on your tolerance for dealing with that.  The rate
> of change can also be an issue if the tests you're intersted in are
> expensive.  OTOH if you're doing things that are likely to be affected
> by changes in a broad set of trees (eg, maintaining some embedded
> platform where you care about all the various subsystems breaking
> platform specific drivers) it can be a lot easier to cover -next rather
> than all the individual subsystems.

You said it much better than I did, thank you!

For me, -next is a convenient point to test much of what will be going in.
Yes, it can be frustrating, finding problems just as someone else fixed
them, finding problems irrelevant to any of my use cases, and so on.
But sometimes I find something that would have been quite painful to
deal with later in process that others don't find.  Overall, it is well
worth the my effort.

							Thanx, Paul

  reply	other threads:[~2024-10-24  2:51 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-21 16:07 Sasha Levin
2024-10-21 17:18 ` Matthieu Baerts
2024-10-21 17:36   ` Sasha Levin
2024-10-22  9:11     ` Matthieu Baerts
2024-10-21 17:24 ` Bart Van Assche
2024-10-21 17:30   ` Sasha Levin
2024-10-21 18:10     ` Luis Chamberlain
2024-10-21 18:36 ` Liam R. Howlett
2024-10-21 19:44   ` Sasha Levin
2024-10-21 22:56     ` Linus Torvalds
2024-10-21 21:41 ` Mark Brown
2024-10-22  9:10   ` Thorsten Leemhuis
2024-10-22 13:19     ` Mark Brown
2024-10-31 19:22     ` Shuah Khan
2024-10-21 23:39 ` Paul E. McKenney
2024-10-22 12:06   ` Jiri Kosina
2024-10-22 14:22     ` Paul E. McKenney
2024-10-22 14:36       ` Sasha Levin
2024-10-22 14:46         ` Paul E. McKenney
2024-10-22  4:54 ` Kees Cook
2024-10-22  6:48   ` Christoph Hellwig
2024-10-22  8:12     ` Steven Rostedt
2024-10-22  9:55       ` Vlastimil Babka
2024-10-22 11:51       ` James Bottomley
2024-10-22 12:47         ` Mark Brown
2024-10-22 19:33       ` Kees Cook
2024-10-23  2:24         ` Guenter Roeck
2024-10-23  5:47       ` Christoph Hellwig
2024-10-23  8:20         ` Steven Rostedt
2024-10-23  8:36           ` Geert Uytterhoeven
2024-10-23  9:19             ` Steven Rostedt
2024-10-23  9:23               ` Geert Uytterhoeven
2024-10-23 10:11               ` Dan Carpenter
2024-10-23 17:51               ` Paul E. McKenney
2024-10-24  3:59               ` Michael Ellerman
2024-10-24  5:01                 ` Steven Rostedt
2024-10-24  5:16                   ` Guenter Roeck
2024-10-24  6:49                     ` Steven Rostedt
2024-10-24  7:01                       ` Geert Uytterhoeven
2024-10-24  9:21                         ` Steven Rostedt
2024-10-24  9:24                           ` Christoph Hellwig
2024-10-24  9:49                             ` Steven Rostedt
2024-10-24 11:08                               ` Mark Brown
2024-10-24 11:14                                 ` Christoph Hellwig
2024-10-25 21:04                               ` Jiri Kosina
2024-10-24 14:39                       ` Guenter Roeck
2024-10-25  1:11                         ` Steven Rostedt
2024-10-25  3:52                           ` Guenter Roeck
2024-10-25 11:18                           ` Mark Brown
2024-10-25 17:23                           ` Paul E. McKenney
2024-10-24 17:53                       ` Luis Chamberlain
2024-10-25  1:17                         ` Steven Rostedt
2024-10-25  2:07                           ` Luis Chamberlain
2024-10-31 19:08               ` Shuah Khan
2024-10-31 19:19                 ` Steven Rostedt
2024-10-23  9:32           ` Vlastimil Babka
2024-10-23 10:18             ` Thorsten Leemhuis
2024-10-23 11:41           ` James Bottomley
2024-10-22  9:37     ` Sasha Levin
2024-10-23  5:50       ` Christoph Hellwig
2024-10-23 17:47         ` Paul E. McKenney
2024-10-23 18:05           ` Guenter Roeck
2024-10-23 18:09             ` Linus Torvalds
2024-10-23 18:50               ` Geert Uytterhoeven
2024-10-23 18:06           ` Linus Torvalds
2024-10-23 18:37             ` Paul E. McKenney
2024-10-23 19:24               ` Linus Torvalds
2024-10-23 20:22                 ` Paul E. McKenney
2024-10-23 21:20             ` Theodore Ts'o
2024-10-23 21:24             ` Mark Brown
2024-10-24  2:51               ` Paul E. McKenney [this message]
2024-10-22 10:52     ` Sasha Levin
2024-10-22 11:50       ` Mark Brown
2024-10-22 14:47         ` Sasha Levin
2024-10-22 15:25           ` Mark Brown
2024-10-28 22:46     ` Sasha Levin
2024-10-29  8:10       ` Thorsten Leemhuis
2024-10-29 11:30         ` Sasha Levin
2024-10-29 12:46           ` Thorsten Leemhuis
2024-10-29 15:07             ` Sasha Levin
2024-10-30  6:46               ` Thorsten Leemhuis
2024-10-30 14:10                 ` Sasha Levin
2024-10-31  8:13                   ` Thorsten Leemhuis
2024-10-29  8:20       ` Geert Uytterhoeven
2024-10-30 17:08       ` Paul E. McKenney
2024-10-30 17:15         ` Sasha Levin
2024-10-30 17:32           ` Paul E. McKenney
2024-11-04  8:49       ` Joel Granados
2024-11-04 11:01         ` Sasha Levin
2024-11-25 20:05       ` Joel Granados
2024-10-22  7:02   ` Geert Uytterhoeven
2024-10-22  8:41   ` Benjamin Tissoires

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=d8087943-0a9c-4e1e-8873-48a15e1311dc@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=broonie@kernel.org \
    --cc=hch@infradead.org \
    --cc=kees@kernel.org \
    --cc=ksummit@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=torvalds@linux-foundation.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