[lkml]   [2005]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Giving developers clue how many testers verified certain kernel version
Hi Adrian,
I think you don't understand me. I do report bugs and will always
do. The point was that developers could be "assured" there is possibly
no problem when people do NOT report bugs in that piece of code
because they would know that it _was_ tested by 1000 people on 357 different
HW's. And they could even check the .configs, lshw etc. Sure the people
would report a problem, but if you do NOT hear of one then there is either no
problem or nobody cared to report that or nobody tested. So you known
just nothing and you better wait some days, weeks so the patch get's lost
in lkml archives if it doesn't happend it gets into -ac or -mm.

And that is exactly why I proposed this. Then you will know that 1000
people really cared and used that and most probably then it is reasonable
to expect there is really no bug in the code.

Take it the other way around. You may be reluctant to commit some
patch to the official tree. ;) The guy who wrote the patch says "It was tested,
please apply". ;-) If he says the patch is lying in -mm or -ac tree for
a while - like 2 months you might be more in favor to commit, right?
If you know the patch was tested between -git5 and -git6 by 1000 people
within 5 days you wouldn't wait either, right?

Adrian Bunk wrote:
> On Sun, Jul 24, 2005 at 08:45:16PM +0200, Martin MOKREJ? wrote:
>> well, the idea was to give you a clue how many people did NOT complain
>>because it either worked or they did not realize/care. The goal
>>was different. For example, I have 2 computers and both need current acpi
>>patch to work fine. I went to bugzilla and found nobody has filed such bugs
>>before - so I did and said it is already fixed in current acpi patch.
>>But you'd never know that I tested that successfully. And I don't believe
>>to get emails from lkml that I installed a patch and it did not break
>>anything. I hope you get the idea now. ;)
> in your ACPI example there is a bug/problem (ACPI needs updating).
> And ACPI is a good example where even 1000 success reports wouldn't help
> because a slightly different hardware or BIOS version might make the
> difference.
> Usually "no bug report" indicates that something is OK.
> And if you are unsure whether an unusual setup or hardware is actually
> tested, it's usually the best to ask on linux-kernel whether someone
> could test it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-24 21:14    [W:0.028 / U:1.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site