[lkml]   [2003]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Testing: What do you want?
    On Mon, 2003-03-24 09:46:05 -0500, Scott Robert Ladd <>
    wrote in message <>:
    > For the most part, the 2.5 series has worked very well for me, albeit
    > with a few glitches (radeonfb, for example, as reported last week.) I'll
    > build the 2.5.65 kernel on my Sparc later today, and see how well it
    > works there.

    sparc32? If you get it to build or even to boot, please drop me a note
    with at least this information I'm *really* interested in:

    - Machine type
    - CPU(s)
    - .config file
    - gcc -v
    - ld -v

    Last time I looked at it, sparc32 wasn't in any good state (esp. SMP) in
    2.5.x. This is because Dave S. Miller stopped spending a lot of hacking
    time (he has to work for other things now and only merges patches he
    gets sent, where he formerly did tons on active development for

    I'm in the progress of a (private) attempt to build a Linux Test Centre.
    (I've already mentioned that - read my last mail in the thread
    aboutremoving .gz files from

    The idea is to have automatic kernel builds (for all available
    architectures I've collected test hardware for:) and run tests. This
    needs to be achieved with automatic cross-compilation of kernels (you
    don't want to let a m68k compile it's own kernel:), installation and
    choosing this for booting. I've got some quite nice ideas there
    (including electronic power switches, serial console management etc.),
    but yet, I'm not assured that I'll get the room I may get near
    Halle/Westf (Germany).

    What is _most_ important to testing is this:

    - *fast* response.
    Developers don't like to wait like a month
    before they hear they broke something. If there
    are (untested) patches timely in between, it may
    even get hard to sort the broken part out (cf.
    sparc32 at 2.5.x).

    So the basics are doing automated _compile_
    tests. This includes keeping tables (file name -
    responsible person, architecture - responsible
    person) for automated notification, as well as a
    quite good system to switch certain .config
    items off (so if you find some compile error,
    you have to automatically (if possible) switch
    off the corresponding feature and start again).

    - Decoded Oopses.
    With the in-kernel kksymoops, this is (most of
    the time) quite easy to do if you've got serial
    console working.

    Possibly implementing kgdb for more
    architectures could help also.

    If you then get an answer by a developer, you
    also need to response on a fast manner. Give any
    information to the developers as early as
    possible. They don't like asking for every
    piece. They like mails containing anything they
    need (structured and readable).

    If you then receive patches for review, you'd
    also be capable of automatically including them,
    starting a new compile/install/boot-up, ...

    - Runtime test (stability).
    Some Kernels first start booting, but freeze
    days later. These are the hard ones:( By
    possibility, you haven't got any information on

    ...and all this for as many machines/architectures with as different as
    possibly hardware attached.

    MfG, JBG

    Jan-Benedict Glaw . +49-172-7608481
    "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
    ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 13:34    [W:0.049 / U:12.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site