Re: Giving developers clue how many testers verified certain kernel version
From: Alejandro Bonilla (abonilla_at_linuxwireless.org)
Date: Thu, 21 Jul 2005 21:40:43 -0500 To: Martin MOKREJŠ <email@example.com>
Martin MOKREJŠ wrote:
> 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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/