From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Christoph Hellwig <hch@infradead.org>
Cc: 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: Tue, 22 Oct 2024 07:51:03 -0400 [thread overview]
Message-ID: <a4d7222ddb039a03a337fcfb047f5e804bc541d4.camel@HansenPartnership.com> (raw)
In-Reply-To: <20241022041243.7f2e53ad@rorschach.local.home>
On Tue, 2024-10-22 at 04:12 -0400, Steven Rostedt wrote:
> On Mon, 21 Oct 2024 23:48:34 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
>
> > > How about this, instead: no one sends -rc1 PRs to Linus that
> > > didn't go through -next. Just have a bot that replies to all PRs
> > > with a health check, and Linus can pull it if he thinks it looks
> > > good.
> >
> > Not just -rc1, otherwise agreed.
>
> You mean have everything go into linux-next before going to Linus
> after -rc1?
I think that's a good goal, yes. Most developers tend to send a fixes
pull around once a week (or less) after the merge window, which means
it could be soaked in -next.
> I'm one that doesn't do this. That's because my code in linux-next
> after -rc1 is for the next merge window, and the code I send to Linus
> is only fixes for code I sent before -rc1. I tend to keep an "urgent"
> and "core" branch. My "core" branch is everything I plan to send in
> the next merge window and goes into linux-next (via being pulled into
> my for-next branch). After I send my pull request to Linus, and he
> pulls it in the merge window, that "core" branch becomes my "urgent"
> branch.
>
> But when I find a bug that's in Linus's tree, I put the fix on top of
> "urgent", run it through my test suite (takes 8 hours or so), then
> send a pull request to Linus. My "urgent" branch doesn't go into
> linux-next as it doesn't have changes that should affect others work,
> which is what I think linux-next is mostly for.
That's not necessarily a safe assumption. The reason we put scsi-fixes
into -next is precisely to pick up if this happens. I admit it happens
very rarely because of the compact and local nature of the fixes, but
the signal rate isn't zero.
> I also find known bugs in Linus's tree to be high priority to be
> fixed (I stop what I'm doing to get the fix out ASAP).
>
> Now, if there was better testing from linux-next, maybe it would be
> worth the time to push my urgent branch there for a bit. But so far I
> haven't seen the benefit of doing that.
It does at least get 0day running over it, although that can also be
configured for your branches separately as well. It's also not unwise
to have some pause time before fixing and sending ... the fix you first
thought of isn't always the best one (or even sometimes an actual fix).
Regards,
James
next prev parent reply other threads:[~2024-10-22 11: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 [this message]
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
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=a4d7222ddb039a03a337fcfb047f5e804bc541d4.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=hch@infradead.org \
--cc=kees@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--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