When patchwork integration is configured, b4 will now retrieve the CI status of each patch as well.

@monsieuricon @palmer oh this is neat

@conor @monsieuricon ya, this is super cool. I guess I'm upgrading b4 this weekend...

@monsieuricon Nice.
It's not working for linuxppc because our checks are posted on the final patch of the series.
I can make it work if I drop the skip case when the first patch has no status.

@mpe oh, that's an interesting use of checks. Why not post them for every patch?

@monsieuricon Because these checks are "apply the series and do a bunch of build & boot tests", which is too expensive to do for every patch.

@mpe how about running some cheap checks per-patch, like checkpatch or kunit, etc?

@monsieuricon Yeah we could end up doing that one day. Even so we might skip checks for eg. documentation only patches. So I guess my point is a single patch with no checks doesn't necessarily mean there are no checks on later patches.

@mpe noted! I'll probably remove that check or at least give it more thought. We can parallelize ci status lookups to speed them up, too.

should start using patchwork again for a test run. had totally forgotten its existence not to disregard its usefulness. since i use b4 already with lore, i'll test run this for a some patch set under review, thanks for reminder :-)

@monsieuricon is there any plans to have some tool level interaction with kernel bugzilla? that is sort of forum that gets easily disregarded because LKML is the top priority. with better tooling it would be easier to provide better service. right now the bugzilla feels sort of separate island where you have to take a boat to visit and do your business, and then come back to the mainland.

@monsieuricon @mpe that's what we do for the #MPTCP subsystem using GitHub Actions:

- Each commit is built separately and checkpatch is also executed on each patch.
https://github.com/multipath-tcp/mptcp-upstream-validate-export-action

- Tests are executed once on the last patch of the series.
https://github.com/multipath-tcp/mptcp-upstream-virtme-docker

- Everything is sent to patchwork later. The tests result is duplicated on each patch.
https://github.com/multipath-tcp/mptcp_net-next/tree/export/.github/workflows

(It's just a shame this has to be done differently for each subsystem)

@jarkko Yes, the bugbot fully bridges the mailing lists and bugzilla. I just need to find some time to actually complete the integration. https://git.kernel.org/pub/scm/utils/bugspray/bugspray.git/

@monsieuricon @jarkko

Thx for your work on this.

Really looking forward to the day where we can use bugbot on bugs without reassigning them to a specific product/component. I recently had a situation again where that topic came up.

@monsieuricon awesome thanks

@monsieuricon awesome!

@monsieuricon FYI, this won't work for the intel-gfx mailing list, as patchwork-fdo (forked long ago) operates on series and series revisions rather than per-patch.

Running our CI on all patches would pretty much kill the entire point of CI as it would increase testing latency way too much: Imagine if we only boot-tested a 100-patches series... It would easily take 3 hours for very little benefit. Instead, in this time, we can run thousands of tests... but once per revision of the series.