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

[Guenter Roeck]

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