Thread (146 messages) 146 messages, 44 authors, 2007-11-19

Re: [BUG] New Kernel Bugs

From: Daniel Barkalow <hidden>
Date: 2007-11-15 16:19:46
Also in: alsa-devel, linux-ide

On Thu, 15 Nov 2007, Theodore Tso wrote:
On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
quoted
I don't see any reason that we couldn't have a tool accessible to Ubuntu 
users that does a real "git bisect". Git is really good at being scripted 
by fancy GUIs. It should be easy enough to have a drop down with all of 
the Ubuntu kernel package releases, where the user selects what works and 
what doesn't.
It's possible users who haven't yet downloaded a git repository have
to surmount some obstacles that might cause them to lose interest.
First, they have to download some 190 megs of git repository, and if
they have a slow link, that can take a while, and then they have to
build each kernel, which can take a while.
It should be possible for it to clone only the portion that they actually 
care about based on where the known-good version is. It should also (in 
theory, anyway) be possible to put off some amount of the download until 
it's actually going to be relevant.
A full kernel build with everything selected can take good 30 minutes or 
more, and that's on a fast dual-core machine with 4gigs of memory and 
7200rpm disk drives. On a slower, memory limited laptop, doing a single 
kernel build can take more time than the user has patiences; multiply 
that by 7 or 8 build and test boots, and it starts to get tiresome.
None of this is going to take as long, even on a slow link and a slow 
computer, as waiting for a response to a mailing list post. It'd annoy 
users who are specifically waiting for it, but if the interface is that 
the user says "kernel package X didn't work but the current kernel does", 
and it says "I'll let you know when I've got something to test", and the 
user watches a DVD, and afterward finds a message saying there's something 
to test, and tries it, and reports how it went, and the process repeats 
until it narrows it down to a single commit after a couple of days of the 
user getting occasional responses, it's not that different from asking for 
help online.
And then on top of that there are the issues about whether there is
enough support for dealing with hitting kernel revisions that fail due
to other bugs getting merged in during the -rc1 process, etc.
Could have a distro-provided mask of things that aren't worth testing and 
possibly back-ported fixes for revisions in particular ranges.
I agree that a tool that automated the bisection process and walked
the user through it would be helpful, but I believe it would be
possible for us do better.
That would probably help for giving the user something to try right away. 
I still think that the main cost to the user is the number of times that 
the user has to stop doing stuff to reboot with a kernel to test, whether 
the test kernels are available quickly from the distro site, slowly built 
locally, or slowly as suggested by humans helping online.

	-Daniel
*This .sig left intentionally blank*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help