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: <e7bc3cfe-f7c0-4d8b-b89d-a2f260d34a76@kernel.org>
Date: Mon, 21 Oct 2024 19:18:38 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Sasha Levin <sashal@...nel.org>
Cc: ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 torvalds@...ux-foundation.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

Hi Sasha,

On 21/10/2024 18:07, Sasha Levin 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
> 
>     3. Higher code quality expectation (these are pull requests that
>     maintainers expect Linus to pull)

That's a good idea! Thank you for putting this in place!

If you don't mind, I have some questions below.

>     4. Continuous tree (not daily tags like in linux-next),
>     facilitating easier bisection

What will happen when a pull request is rejected?

(...)

> We also want to avoid altering the existing workflow. In particular:
> 
>     1. No increase in latency. If anything, the expectation is that
>     the cadence of merges would be improved given that Linus will
>     need to do less builds and tests.
> 
>     2. Require "sign up" for the tree like linux-next does. Instead,
>     pull requests are monitored and grabbed directly from the
>     mailing list.

Out of curiosity: is it done automatically? Will it email someone when a
conflict is found?

(...)

> Current testing:
>   - LKFT: https://qa-reports.linaro.org/lkft/sashal-linus-next/
>   - KernelCI: https://t.ly/KEW7F

That's great to have more tests being executed! Who is going to monitor
the results? This task can quickly take time if this person also has to
check for false positives and flaky tests.

Are the maintainers supposed to regularly monitor the results for the
tests they are responsible for? Or will they be (automatically?) emailed
when there is a regression?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.