public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Bonilla <abonilla@linuxwireless.org>
To: "Martin MOKREJŠ" <mmokrejs@ribosome.natur.cuni.cz>
Cc: Mark Nipper <nipsy@bitgnome.net>, linux-kernel@vger.kernel.org
Subject: Re: Giving developers clue how many testers verified certain kernel version
Date: Thu, 21 Jul 2005 21:40:43 -0500	[thread overview]
Message-ID: <42E05CAB.9020703@linuxwireless.org> (raw)
In-Reply-To: <42E05C17.2000305@ribosome.natur.cuni.cz>

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

  reply	other threads:[~2005-07-22  3:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22  1:34 Giving developers clue how many testers verified certain kernel version Martin MOKREJŠ
2005-07-22  2:10 ` Mark Nipper
2005-07-22  2:38   ` Martin MOKREJŠ
2005-07-22  2:40     ` Alejandro Bonilla [this message]
2005-07-22 23:22       ` Adrian Bunk
2005-07-22 23:11 ` Adrian Bunk
2005-07-24 18:45   ` Martin MOKREJŠ
2005-07-24 18:54     ` Adrian Bunk
2005-07-24 19:10       ` Martin MOKREJŠ
  -- strict thread matches above, loose matches on Subject: below --
2005-07-23  0:44 Blaisorblade
2005-07-23  0:50 ` David Lang
2005-07-23  0:59   ` H. Peter Anvin
2005-07-23  1:07 ` Alejandro Bonilla
2005-07-23  3:09   ` Lee Revell
2005-07-23  2:15     ` Alejandro Bonilla
2005-07-23  3:21       ` Lee Revell
2005-07-23  2:34         ` Alejandro Bonilla
2005-07-23  3:31         ` Linus Torvalds
2005-07-23  2:40           ` Alejandro Bonilla
2005-07-23  3:34           ` Lee Revell
2005-07-23  9:05             ` Con Kolivas
2005-07-23 16:45               ` Lee Revell
2005-07-23  3:56       ` Adrian Bunk
2005-07-23  9:21 ` Jesper Krogh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42E05CAB.9020703@linuxwireless.org \
    --to=abonilla@linuxwireless.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmokrejs@ribosome.natur.cuni.cz \
    --cc=nipsy@bitgnome.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox