linux-kernel - Re: linus-next: improving functional testing for to-be-merged pull requests

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: <ed2be51d-d294-498e-86dc-1d76b33e376c@suse.cz>
Date: Tue, 22 Oct 2024 11:55:26 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Steven Rostedt <rostedt@...dmis.org>,
 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 10/22/24 10:12, Steven Rostedt wrote:
> 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.

I've seen somewhere mentioned (but can't now find where it was) that -next
has a pending-fixes branch [1] that's exactly intended to collect hotfix
branches from maintainer trees separately from the true "for next merge
window" branches. And that one of the points from the maintainers summit was
that this would be made more widely known and expected of maintainers to
use. Can anyone confirm?

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=pending-fixes

>> 
>> > 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
>