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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux