On Wed, 25 Nov 2020 10:37:20 -0700 David Ahern wrote: > On 11/25/20 9:47 AM, Jakub Kicinski wrote: > > On Tue, 24 Nov 2020 21:37:18 -0700 David Ahern wrote: > >> On 11/24/20 6:58 PM, Jakub Kicinski wrote: > >>> But it's generally not a huge issue for applying the patch. I just like > >>> to see the build bot result, to make sure we're not adding W=1 C=1 > >>> warnings. > >> > >> ah, the build bot part is new. got it. > > > > BTW I was wondering for the longest time how to structure things so > > that build bot can also build iproute2 in case we want to run tests > > attached to the series and the tests depend on iproute2 changes... > > > > But let's cross that bridge when we get there. > > Why not cross it now? You handled the switch over to new a patchworks > with a build bot, so we can take advantage of automation. > > Seems like the bot needs to detect 'net', 'net-next', 'bpf' and > 'bpf-next' as they are all different trees for the kernel patches. > iproute2 is just another tree, so it should be able to put those in a > different bucket for automated builds - even if it means a 'set' crosses > trees. Actually part of the reason is that we use up 32 vCPUs just to do build testing. I don't think we can afford to individually selftest every series. And if we only run the tests ~nightly we can grab all outstanding patches for iproute2 from the ML and we should be good. At least that's my current thinking. I probably won't have time to implement any of this until Dave is back 100% and then some, anyway ;)