Re: Giving developers clue how many testers verified certain kernel version

[Alejandro Bonilla <abonilla@linuxwireless.org>]

Martin MOKREJŠ wrote:

> Hi,
>
> Mark Nipper wrote:
>
> >     I have a different idea along these lines but not using
> > bugzilla.  A nice system for tracking usage of certain components
> > might be made by having people register using a certain e-mail
> > address and then submitting their .config as they try out new
> > versions of kernels.
>
> Nice idea, but I still think it is of interrest on what hardware
> was it tested. Maybe also 'dmesg' output would help a bit, but
> I still don't know how you'd find that I have _this_ motherboard
> instead of another.
I'm a simple Linux user that normally likes to test as much things as 
posible. This is what I would do:
I would make a Summary of the ChangeLog that was done to the kernel, and 
from there encourage people to test those parts. The worst part that I 
face against Linux is that I don't know C enough like to understand what 
the patch that someone sent will really do.
   A user understandable ChangeLog so that people can test those 
changed points would be great. And if those changes could have an 
explanation on how users could troubleshoot the change, then it would be 
fairly awesome.
   I have been subscribed here for more than a year already, and I have 
barely understood a couple of changes that have been done to Drivers and 
to the kernel itself. How can I make sure that the change will really 
work better for me?
   How does one check if hotplug is working better than before? How do 
I test the fact that a performance issue seen in the driver is now fixed 
for me or most of users? How do I get back to a bugzilla and tell that 
there is a bug somewhere when one can't really know if that is the way 
it works but is simply ugly, or if there is really a bug?
   My point is that a user like me, can't really get back to this 
mailing list and say "hey, since 2.6.13-rc1, my PCI bus is having an 
additional 1ms of latency" We don't really have a process to follow and 
then be able to say "ahha, so this is different" and then report the 
problem, even if we can't fix it because of our C and kernel skills.
   How do we know that something is OK or wrong? just by the fact that 
it works or not, it doesn't mean like is OK.
There has to be a process for any user to be able to verify and study a 
problem. We don't have that yet.
.Alejandro
-
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/