lkml.org 
[lkml]   [2002]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: real BK usage (was: A modest proposal -- We need a patch penguin)
    On Jan 31, 2002  09:11 -0800, Larry McVoy wrote:
    > On Wed, Jan 30, 2002 at 01:03:19PM -0700, Andreas Dilger wrote:
    > > Yes, technically it works fine, but practically not. For example, I want
    > > to test _all_ of the changes I make, and to test them each individually
    > > is a lot of work. Putting them all in the same tree, and testing them
    > > as a group is a lot less work. More importantly, this is how people do
    > > their work in real life, so we don't want to change how people work to
    > > fit the tool, but vice versa.
    >
    > This thread has been about the idea of being able to send any one of those
    > changes out in isolation, right? That's the problem we are solving.

    But what you are proposing is that I keep N trees for each of my N changes
    against the baseline, keep all of those N trees up-to-date, compile
    and reboot each of the N kernels for each local or upstream change, and
    possibly have N! different kernels to test each combination of changes.

    > But your statement is that you want to test them all at once, testing
    > them one at a time is too much work.

    I guess I wasn't very clear then. I will probably test changes I make
    in _order_, but not necessarily in _isolation_. I may also not test
    _every_ change I make individually if it is fairly minor and "obvious".
    If the changes are orthogonal, testing kernel+A and testing kernel+A+B
    should be enough to tell me that B works without A. That means I should
    be able to send out B without everyone needing A in order to test it.

    > Doesn't that mean that you don't even know if these changes compile, let
    > alone run, when you send them out individually? You haven't tested them,
    > you've only tested the set of them as one unit.

    It boils down to "how much testing is enough" for each of the separate
    changes. Is eyeballing them enough? Is compiling enough? Is a single
    reboot enough? I don't have N machines, let alone N!, to test each of
    the N changes I have in my tree individually.

    There is also value in saying "I've had this patch in my kernel for X
    {days,weeks,months} and it works fine", and by your statement above I
    could only do this with a single change.

    What I'm saying is that I will code a specific change A, test it, and then
    usually go on to code the next change B in the tree that has A in it.
    Yes, in some cases testing B in isolation is needed (big changes, or
    changes which need to be benchmarked in isolation). In general you
    wouldn't make change A if it wasn't worthwhile, and after it's done why
    would you not want to continue using it?

    Cheers, Andreas
    --
    Andreas Dilger
    http://sourceforge.net/projects/ext2resize/
    http://www-mddsp.enel.ucalgary.ca/People/adilger/

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:16    [W:4.153 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site