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: <3f71da6a-ab96-42c6-9c61-c73f2b6dceb0@linuxfoundation.org>
Date: Thu, 31 Oct 2024 13:22:30 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Thorsten Leemhuis <linux@...mhuis.info>, Mark Brown <broonie@...nel.org>
Cc: torvalds@...ux-foundation.org, ksummit@...ts.linux.dev,
 linux-kernel@...r.kernel.org, Sasha Levin <sashal@...nel.org>,
 Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

On 10/22/24 03:10, Thorsten Leemhuis wrote:
> On 21.10.24 23:41, Mark Brown wrote:
>> On Mon, Oct 21, 2024 at 12:07:13PM -0400, 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:
> 
> BTW, in case anyone cares: I fully agree with what Kees wrote earlier
> today elsewhere in this thread, e.g. things like "improve -next instead"
> and "pre-merge bot":
> http://lore.kernel.org/all/792F4759-EA33-48B8-9AD0-FA14FA69E86E%40kernel.org\

I am catching up on this thread. I agree with Kees and others on improve
next instead. Adding one more next-like-thing will add to the confusion.

> 
> Regarding that bot: a few of the CI folks and a developer or two told me
> they want regzbot to react to PRs for Linus as well, so it can send
> mails like "hey Linus, just so you know, this PR contains changes that
> cause the following regressions not yet fixed". I think I like the idea,
> but well, quite a few other improvements around regzbot and its use have
> a much higher priority currently.
> 
>>> 	4. Continuous tree (not daily tags like in linux-next),
>>> 	facilitating easier bisection
>>
>> Is this a pressing problem?  I routinely bisect -next, you have to base
>> things on Linus' tree (or pending-fixes) but otherwise it's not
>> especially problematic.
> 
> I wonder if part of this is a "don't know how to do that" aka "lack of
> documentation" problem. I've recently seen some good guide or mailing
> list post how to bisect -next somewhere, but I think it wasn't in our
> Documentation/ directory. I need to search where that was (Mark, I might
> misremember, but wasn't it you who posted it somewhere?) and could work
> towards upstreaming that or some other guide. And don't worry, due to
> the different target audience it would be much shorter text than other
> documents I contributed. ;-)
> 

Documentation could help. Tailoring the workflow to linux-next could help.
All my branches are in linux-next. I don't send my PRs without keeping
the content in linux-next for 3 days to week after rc1 - it is usually
longer for merge-window content.

This helps me find conflicts if any between all the tree selftest go
through and mine. It helps work out conflicts in linux-next prior to
sending pull request.

My vote is for improving next instead of re-inventing next-like-thing.

thanks,
-- Shuah