KS2009: Regressions

Posted Oct 24, 2009 10:47 UTC (Sat) by modernjazz (guest, #4185)
Parent article: KS2009: Regressions

If the issue is getting more testers, then it seems clear that the "easy"
solution is to start making real use of the data in the distributions' bug
trackers. Since the distribution developers are swamped, people who care
about the kernel should be browsing the distribution bug databases
themselves. Saying "we need more testers!" but then not exploiting this
resource seems somewhat disingenuous.

to post comments

KS2009: Regressions

Posted Oct 25, 2009 6:42 UTC (Sun) by kreutzm (guest, #4700) [Link]

Although not mentioned in the text, I guess the real problem here is that distribution kernels tend to be old by kernel developer standards. And if someone reported "my upgrade from Etch to Lenny broke ..." then it is not clear that this person would be able to either git-bisect the exact faulty patch nor that he would be able to run the latest kernel (which might not even run out of the box).

The dull (but probably) working solution would be if someone with deep knowledge of kernel regression would occassionally run through the distribution BTSs and mark things "fixed-upstream" when he notices that some regression is already solved, so that the reporter knows about it (and maybe the distro can cherry pick something if they so desire). But I can hardly estimate how much this would actually help.

Maybe someone with lots of disk space could regularly compile the latest kernels (lets say every stable, -rc, ..) for all major distributions such that "mere mortals" could yum or apt-get them. Then experienced users could narrow the problem down by quite a bit and either distro kernel people could jump in (if the problem is solved in kernels newer than the one shipped) or kernel devs could notice if it is still present in the latest upstream one. This, and a good explanation of the procedures involved (git-bisect, ....) could maybe help some more.