[alsa-devel] [BUG] New Kernel Bugs
barkalow at iabervon.org
Thu Nov 15 17:19:46 CET 2007
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
> 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.
*This .sig left intentionally blank*
More information about the Alsa-devel