Re: Reduced build and test coverage
"Guillaume Charles Tucker" <[email protected]>
| Newsgroups | dev.linux.lists.kernelci |
|---|---|
| Message-ID | <84e-6509cf80-5-78984280@144048748> |
On Tuesday, September 19, 2023 18:12 CEST, Mark Brown <[email protected]> wrote: > On Tue, Sep 19, 2023 at 04:44:06PM +0200, Ricardo Cañuelo wrote: > > On mar, sep 19 2023 at 15:31:31, Mark Brown <[email protected]> wrote: > > > If we're doing this -next would be very helpful too. > > > Does it make sense to bisect -next, though? Considering that it's > > constantly rebased, so I don't think it has a coherent and "linear" log > > like mainline. That means that bisections aren't guaranteed to work on > > it. Is that right? > > When bisecting -next you should generally bisect it against the mainline > it was based on. Yes that's how the KernelCI bisection works. It's the most useful branch to bisect automatically precisely because it's rebased every day with thousands of commits, so a bisection takes between 10 and 15 iterations and it's painful to do manually. And that's where most of the bugs are. Then mainline, stable and stable-rc are the other critical trees to cover so it makes sense to enable them first. We've discussed enabling bisections again with sysadmins and I think we can have this done in a week or two. Other issues are about measuring costs empirically for different parts of the system and adding a filter in the legacy back end to avoid flooding Jenkins with jobs that won't get run (they still use up all the RAM). Cheers, Guillaume