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

[Guenter Roeck <linux@roeck-us.net>]

On 10/24/24 18:11, Steven Rostedt wrote:
> On Thu, 24 Oct 2024 07:39:00 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
> 
>>>
>>> Now I have to ask. What's the benefit of pushing to linux-next over
>>> waiting for the zero-day bot?
>>>    
>>
>> I push my changes into the same branches that are checked by 0-day
>> and pulled into linux-next. linux-next shows interference with other
>> branches. Once in a while I do get a notification telling me that
>> one or more of the patches interfere with other patches, so I know that
>> something happened, and I can prepare for that for the next commit window.
> 
> Remember, this is about pushing to linux-next before sending fixes
> after -rc1. Not for things that are going to land in the next merge
> window. My fixes seldom ever interfere with others work as it's usually
> much more focused on code that is already in Linus's tree. Like adding
> a missing mutex_unlock() from an error path. How is it helpful to push
> something like that to linux-next?
> 

I still try to have my patches rest in -next for a few days before sending
a pull request to Linus. At the very least this gives others a chance to
pick up those patches if they encounter a problem fixed by them. Also,
sometimes bug fixes do introduce new problems, so, yes, I think it is
very useful to have as many eyes (or test systems) as possible look
at them before sending a pull request.

>>
>> Testing-wise, I do run build and boot tests on linux-next (the same tests
>> as those running on release candidates), so I do know what is wrong there
>> and (which did happen a couple of times) if a patch in one of my trees
>> is responsible.
>>
>> Yes, that means that in many cases I do know ahead of time which problems
>> are going to pop up in the mainline kernel. But I don't have the time
>> tracking those down when seen in linux-next - there are just too many
>> and, as already mentioned, that would be a full-time job on its own.
>> Also, it happens a lot that they have been reported but the report was
>> ignored or missed. On top of that I found that _if_ I am reporting them,
>> the receiving side is at least sometimes either not responsive to almost
>> abusive, so for the most part I gave up on it (and frankly I found that
>> people tend to be _much_ more responsive if one Linus Torvalds is listed
>> in Cc:).
>>
>> Note that I do collect known fixes in my 'fixes' and 'testing' branches,
>> primarily to have something clean available to keep testing. Linus even
>> pulled my fixes branch once directly because the responsible maintainers
>> didn't send pull requests to him for weeks.
> 
> Or are you saying that it's helpful to "fix" linux-next before fixing
> Linus's tree? That way others will have the fixes too?
> 

My fixes and testing branches apply on top of mainline. All patches in the fixes
branch have been sent to maintainers, and they _should_ be (and for the most
part are) available in linux-next. If they are not, the maintainers did not
respond to the patch e-mails or push them out to any branch that is used to
generate -next. The only exception is if I needed to revert some patch to work
around a problem, but even then I make sure that the responsible maintainer
knows about the problem (if they read their email).

Guenter