On Tue, Nov 13, 2007 at 02:12:57PM -0500, Mark Lord wrote:
Adrian Bunk wrote:
On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote:
Adrian Bunk wrote: ...
I did bisecting myself, and I know that it costs time and work.
But the first point is the above one that it makes otherwise nearly undebuggable problems debuggable and fixable.
..
Definitely useful, no question.
But the problem is now that kernel devs are addicted to it, many won't even consider resolving a problem any other way.
That's not "maintaining" (or supporting) one's code.
What you replaced with two dots contained the answer to this:
Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports is a quite scarce resource.
And when a "maintainer" is too busy to find/fix their own bugs, that could be a sign that they've bitten off too big of a chunk of the kernel, and it's time for them to distribute code maintainership.
The problem is: Maintainers don't grow on trees.
You need people who are both technically capable and willing to spend time on the non-sexy task of debugging problems.
Where do you plan to find them?
If you don't believe me, please find a maintainer for the currently unmaintained parallel port support.
Or if you want a harder task, find a maintainer for the floppy driver...
..
Again, the problem is:
But the problem is now that kernel devs are addicted to it, many won't even consider resolving a problem any other way.
And that's simply not good enough.
There is this silly limit that noone can work more than 168 hours per week on the Linux kernel, and some kernel developers seem to take the liberty of spending even less time on kernel development...
Considering our problems to cope with the amount of incoming bug reports, everything that would require a kernel developer to spend more time for getting a bug fixed would be a horrible mistake.
cu Adrian