Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

From: david
Date: Sun Jun 17 2007 - 13:45:58 EST


On Sun, 17 Jun 2007, Oleg Verych wrote:

On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
On 17/06/07, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
<michal.k.k.piotrowski@xxxxxxxxx> wrote:

+If the patch introduces a new regression and this regression was not
fixed
+in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think. How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?


Here lays the problem.

git-bisect is a killer app, people should start using it.

It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's "a good thing" for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.

most people who report bugs don't know enough about what's actually going wrong to be able to write a test case (those that do can probably just write a patch to fix it). Along similar lines a debugger wouldn't be of much use either.

the fact that git-bisect doesn't require any knowledge other then knowledge the reporter has demonstrated that they already have (the ability to compile and install their own kernel) puts it within the reach of testers.

unfortunantly, as good as it is it can take a lot of effort, especially if the bug takes time to show up. it's not perfect, but it's a huge help.

and developers aren't always responding with 'do a bisect', sometimes they respond with 'yes, we know about that' or 'that sounds like X', so it's still worthwhile for people to report the problem first before going to the ffort of doing a bisect.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/