Messages in this thread |  | | Date | Sun, 24 Jul 2005 21:10:36 +0200 | From | Martin MOKREJŠ <> | Subject | Re: 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? Martin
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |