lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ