From: Luis Chamberlain <mcgrof@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Michael Ellerman <mpe@ellerman.id.au>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Christoph Hellwig <hch@infradead.org>,
Kees Cook <kees@kernel.org>, Sasha Levin <sashal@kernel.org>,
torvalds@linux-foundation.org, ksummit@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull requests
Date: Thu, 24 Oct 2024 10:53:19 -0700 [thread overview]
Message-ID: <ZxqJj9IZ2GF3IStb@bombadil.infradead.org> (raw)
In-Reply-To: <20241024024928.6fb9d892@rorschach.local.home>
On Thu, Oct 24, 2024 at 02:49:28AM -0400, Steven Rostedt wrote:
> Now I have to ask. What's the benefit of pushing to linux-next over
> waiting for the zero-day bot?
0-day only does build tests by default, there are many places which have
actual run time tests which *run* off of linux-next, those are both bots
and human. Granted you can get your own run time tests out of your own
branches but that's on each developer to set up and a developer's test
exposure of just one branch is small compared to linux-next. For example
I've seen obscure bugs creep up on linux-next for modules which only some
odd arch or setup was able to capture before which no test we had during
development was able to capture. So more exposure to system variability
and test variability.
The other benefit is you get to see *way ahead of time* possible merge
conflicts, and if you can coordinate with the respective maintainers
which your code conflicts with, you can prepare so that this is smooth
sailing upon pull request to Linus.
Luis
next prev parent reply other threads:[~2024-10-24 17:53 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 [this message]
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
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=ZxqJj9IZ2GF3IStb@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hch@infradead.org \
--cc=kees@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mpe@ellerman.id.au \
--cc=rostedt@goodmis.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