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

From: Alejandro Bonilla (abonilla_at_linuxwireless.org)
Date: 07/22/05

  • Next message: Bob Tracy: "Re: Obsolete files in 2.6 tree"
    Date:	Thu, 21 Jul 2005 21:40:43 -0500
    To: Martin MOKREJŠ <mmokrejs@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
    -
    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/


  • Next message: Bob Tracy: "Re: Obsolete files in 2.6 tree"

    Relevant Pages