Message-ID: <Pine.LNX.4.64.0711151034340.12193@iabervon.org>
Date:	Thu, 15 Nov 2007 11:19:46 -0500 (EST)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Theodore Tso <tytso@....edu>
cc:	Benoit Boissinot <bboissin@...il.com>, Mark Lord <liml@....ca>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, protasnb@...il.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	alsa-devel@...a-project.org, linux-ide@...r.kernel.org,
	linux-pcmcia@...ts.infradead.org,
	linux-input@...ey.karlin.mff.cuni.cz,
	bugme-daemon@...zilla.kernel.org
Subject: Re: [BUG] New Kernel Bugs

On Thu, 15 Nov 2007, Theodore Tso wrote:

> On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote:
> > 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*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists