ubuntu-bugcontrol team mailing list archive

[Leann Ogasawara <leann.ogasawara@xxxxxxxxxxxxx>]

Hi Christopher,

Thank you for taking the time to review the KernelBisection wiki and
suggest improvements.  Overall I think your proposal looks fine and
makes sense to be included.  I've inlined just a few minor suggestions
below...

On 07/24/2012 02:32 PM, Christopher Penalver wrote:
> Ubuntu Bug Control / Ubuntu Kernel Team,
>
> 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.
>
> Recent examples:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1022016
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/908825
>
> 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:
>
> *START*
>
> = 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
> <https://launchpad.net/ubuntu/oneiric/+source/linux> . 

I'd suggest using Precise in your example here rather than Oneiric.  I'm
assuming more people will be running the LTS release and so your url
will take them directly to the release they are using.  Additionally,
Precise will be supported for a much longer time frame and thus your
example wouldn't suffer from bit rot as quickly.

> As you will notice, a list of kernels are listed vertically:

I'd suggest specifically pointing out the section as well, eg. "As you
will notice under the "Releases in Ubuntu" section, a series of kernels
are listed vertically:"

> 2.6.38-8.42
> 2.6.39-0.5
> 2.6.39-1.6
> 2.6.39-2.7
> 2.6.39-2.8
> 2.6.39-3.9
> 2.6.39-3.10
> 3.0-0.1
> ....
>
> One would want to test each one until you have the problematic kernel
> immediately preceding the kernel that works. Once this is
>

I think you want to say "until you have the problematic kernel
immediately following the kernel that works."

> done, please continue reading the information below on bisecting
> kernel commits within a given release.
>
> *END*
>
> I did not think a new article needed to be spun off as the existing
> information is invaluable for experienced bisectors.
>
> What do you think?
>
>

Thanks again.  Feel free to incorporate the above suggestions and add it
to the wiki.

Thanks,
Leann