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

[Shuah Khan]

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