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-next>] [day] [month] [year] [list]
Message-ID: <ZxZ8MStt4e8JXeJb@sashalap>
Date: Mon, 21 Oct 2024 12:07:13 -0400
From: Sasha Levin <sashal@...nel.org>
To: torvalds@...ux-foundation.org
Cc: ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: linus-next: improving functional testing for to-be-merged pull
 requests

Hi folks,

The linux-next tree we all know and love is widely used by the kernel
community for integration work. It offers several advantages:

	1. Early detection of conflicts between matinainer trees

	2. Catching most new build errors/warnings

However, it faces significant testing challenges:

	1. Contains a mix of "ready-to-go" code and experimental additions

	2. A single "bad" piece of code can affect testing of everything else

	3. Low barrier of entry, encouraging inclusion over exclusion

	4. While linux-next offers early conflict resolution and
	identifies build issues, it is very difficult to actually test
	due to the abundance of runtime issues it tends to have

These factors combine to make linux-next a valuable tool for integration
but problematic for comprehensive testing.

During the Maintainer's Summit, Linus Torvalds expressed concerns about
the quality of testing that code receives before he pulls it. The
subsequent discussion side-tracked to the testability of linux-next, but
we didn't directly address Linus's original concern about pre-pull
testing quality.

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)

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

The linus-next tree aims to provide a more stable and testable
integration point compared to linux-next, addressing the runtime issues
that make testing linux-next challenging and focusing on code that's
about to be pulled by Linus.

linus-next is (expected to be) particularly effective before the merge
window opens, as maintainers tend to send their pull requests early,
allowing for more thorough testing of to-be-merged changes.

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.

Tree location: `git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linus-next.git linus-next`

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

Feedback and suggestions for improving usability are welcome!

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ