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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWueY8BJKpYrPTh-LKOvBnyyN4k+nHN9u9E9OnGWbVNvA@mail.gmail.com>
Date: Tue, 22 Oct 2024 09:02:27 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Kees Cook <kees@...nel.org>
Cc: 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 Tue, Oct 22, 2024 at 6:55 AM Kees Cook <kees@...nel.org> wrote:
> On October 21, 2024 9:07:13 AM PDT, Sasha Levin <sashal@...nel.org> wrote:
> >In an attempt to address the concerns, we're trying out a new "linus-next"
> >tree is being created and maintained with the following characteristics:
> >
> >       1. Composed of pull requests sent directly to Linus
> >
> >       2. Contains branches destined for imminent inclusion by Linus
>
> But this means hours or a day or 2 at most.
>
> >       3. Higher code quality expectation (these are pull requests that
> >       maintainers expect Linus to pull)
>
> Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

Exactly.

> >       4. Continuous tree (not daily tags like in linux-next),
> >       facilitating easier bisection
>
> I'm not sure how useful that is given the very small time window to find bugs.
>
> >The linus-next tree aims to provide a more stable and testable
> >integration point compared to linux-next,
>
> Why not just use linux-next? I don't understand how this is any different except that it provides very little time to do testing and will need manual conflict resolutions that have already been done in linux-next.

And many actual issues have been seen/worked around in linux-next
a few weeks before.  In addition, this might make people laxer
w.r.t. linux-next, thus increasing Stephen's work load, and making
linux-next worse for actual testing.

> 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.
>
> For example, for a given PR, the bot can report:
>
> - Were the patches CCed to a mailing list?

This check would be good to have for linux-next, too.

> - 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! :)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds