[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241022041243.7f2e53ad@rorschach.local.home>
Date: Tue, 22 Oct 2024 04:12:43 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Kees Cook <kees@...nel.org>, Sasha Levin <sashal@...nel.org>,
torvalds@...ux-foundation.org, ksummit@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
requests
On Mon, 21 Oct 2024 23:48:34 -0700
Christoph Hellwig <hch@...radead.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'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. 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.
>
> > For example, for a given PR, the bot can report:
> >
> > - Were the patches CCed to a mailing list?
> > - A histogram of how long the patches were in next (to show bake times)
> > - Are any patches associated with test failures? (0day and many other
> > CIs are already running tests against -next; parse those reports)
> >
> > We could have a real pre-submit checker! :)
>
> That would be very useful. Items 1 and 2 should be trivial, 3 would
> require a bit of work but would still be very useful.
If there was more feedback to going into linux-next, that would be good.
-- Steve
Powered by blists - more mailing lists