Hello everyone. I wanted to inquire about improving https://wiki.ubuntu.com/Kernel/KernelBisection to further empower Ubuntu community members who run into kernel regression bugs, and want to bisect their own kernels.
During my extensive triaging efforts in the linux package, no original reporter was unwilling to attempt to bisect their kernel regressions. However, due to inexperience, they fall into situations where they would want to have further narrowed down the testing space to one release, and in turn, the regressor/regressee, before bisecting commits.
What I would like to see is a new section added that is just for those who were requested to bisect their kernels, want to give it a go, but just need a little more guidance. This new section would want to be right at the top, as the more experienced members would just skip that information and get right down to it. An example section:
= Before Starting to Bisect Your Kernel Regression =
If you were asked to bisect your kernel due to a regression, were referred to this article, and you are willing to do so, thank you for your efforts! You are taking* the fastest route to get your bug resolved as soon as possible.
The way to minimize the gap between problematic kernels, and minimize the time spent commit bisecting, is to narrow your regression to a specific release. One may use the published linux kernels page https://launchpad.net/ubuntu/+source/linux to help you narrow it down. For example, let us pretend you had a regression within the Oneiric kernel. The published kernels in Oneiric may be found at https://launchpad.net/ubuntu/oneiric/+source/linux . As you will notice, a list of kernels are listed vertically:
One would want to test each one until you have the problematic kernel immediately preceding the kernel that works. Once this is done, please continue reading the information below on bisecting kernel commits within a given release.
I did not think a new article needed to be spun off as the existing information is invaluable for experienced bisectors.