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

[Guenter Roeck]

On 10/23/24 23:49, Steven Rostedt wrote:
> On Wed, 23 Oct 2024 22:16:31 -0700
> Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > I do get notifications, so it is still running.
> > Its configuration is (still) at https://github.com/intel/lkp-tests.git,
> > so you can check yourself if your current repositories and branches are
> > listed (and send a pull request to update it if needed). I see
> >
> > repo/linux/rostedt-kconfig:owner: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > repo/linux/rostedt-ktest:owner: Steven Rostedt <rostedt@xxxxxxxxxxx>
> > repo/linux/rostedt-trace:owner: Steven Rostedt <rostedt@xxxxxxxxxxx>
> >
> > so at least some testing should still happen. I did notice though
> > that "notify_build_success_branch:" is only set in one of the files,
> > so you might not get notified if a build was successful in the other
> > two.
>
> Thanks for the update!
>
> Yeah, I started using topic branches (requested by Linus) and I didn't
> update the success notifications. That explains why I don't receive
> them anymore.
>
> 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.

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.

Guenter