Message-ID: <8e83a3bc-458b-46c0-a3a0-2d6543587fe7@roeck-us.net>
Date: Thu, 24 Oct 2024 20:52:39 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Michael Ellerman <mpe@...erman.id.au>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 Christoph Hellwig <hch@...radead.org>, Kees Cook <kees@...nel.org>,
 Sasha Levin <sashal@...nel.org>, torvalds@...ux-foundation.org,
 ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

On 10/24/24 18:11, Steven Rostedt wrote:
> On Thu, 24 Oct 2024 07:39:00 -0700
> Guenter Roeck <linux@...ck-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

Powered by blists - more mailing lists