lkml.org 
[lkml]   [1998]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectA solution for growing pains
    Date
    It's clear that our fearless leader is, at the moment, a bit overloaded
    so patches may be getting lost. There are some of us, myself among
    them, that have been worried about this for a while and are working on
    a solution. I want to take this time to describe the proposed solution
    and see if people agree that this would help. For what it's worth, I
    think that Linus and some of the other kernel people are interested in
    this solution and now is perhaps a good time to let the rest of you
    in on the thinking.


    The problem
    -----------

    The problem is that Linus doesn't scale. We can't expect to see the rate
    of change to the kernel, which gets more complex and larger daily, continue
    to increase and expect Linus to keep up. But we also don't want to have
    Linus lose control and final say over the kernel, he's demonstrated over
    and over that he is good at that.

    The basic solution
    ------------------

    Figure out a means by which Linus can surround himself with some number
    of people who do part of his job. Add tools which make that possible.
    What I have in mind here works like this:

    Suppose J Random Hacker makes a change to the kernel and posts a patch.
    It's a questionable patch so Linus just ignores it. But suppose somebody
    else a little less random wants to try it out. So they grab it, apply it
    to their tre, tweak it a little and it works. So they post an updated
    patch that includes both their tweaks plus their comments. Now one of
    the first tier folks like Dave or Alan grab it and stuff it into their
    tree. At this point perhaps the patch works fine as is. So they add
    their comments to the patch and send it to Linus.

    What Linus gets is a specific patch with a patch history that shows
    that this patch has been seen to work by several people other than the
    developer, including some people that Linus trusts to have good judgement.
    It still doesn't mean th patch gets applied, it just means that Linus
    has more information in a self contained package.

    If he decides to apply it, the patch goes in and the comment history also
    gets squirreled away as well.

    Details
    -------

    The mechanism which allows all this to happen is a distributed source
    management system. The main features of the system are

    - everybody gets a repository (contrast against the one repository
    model of CVS)
    - changes can be mailed around as "super-patches", also know as
    change sets. A change set is just a patch file that contains
    . all the changes (diffs) but broken up into one revision at a
    time.
    . an identifier that shows where the patch should be applied
    in the tree (patches will fail if you aren't as up to date
    as the sender of the patch)
    . all the revision history for the changes
    . any other metadata such as pathname changes, symbolic tags
    (like alpha2 or linux-2.1.133), etc.
    - a new concept called a line of development (LOD).
    It's logically a branch but it doesn't need to be on a branch.
    Patches can (and will) be their own LOD. You can perform
    operations on a LOD like "apply this to the trunk".

    So how will this work?

    First of all, I'll be putting the kernel (all the old versions) into
    revision control (which is useful in itself). I'll make it available
    for FTP at the end of my little DSL line (and I'll try and get somebody
    to mirror it right away).

    Developers can shlep down the up to date tree, check stuff out and
    get to work. When they get done, there is a command that generates
    the augmented patch (change set) for you. The developer mails that
    to the list and waits.

    Somebody grabs the patch an tries to apply it. This may or may not
    work - it won't work unless that person has an uptodate version of
    the tree - i.e., if the first developer based his work on a more
    recent version of the tree than the second developer, the patch will
    fail when she (the second developer) tries to apply it - with an error
    message that says "the following files are out of date in your tree..."

    The patch can be tested, tweaked, whatever. The she mails it back to
    the list and we repeat the process, getting more and more senior people
    looking at it and forwarding it on.

    Eventually it gets to Linus and he can apply it, test it, change it,
    and finally bless it or reject it.

    That's probably enough hand waving for the moment. If you are
    interested in this topic, please visit http://www.bitmover.com/bitsccs
    and join the mail list described there (the mailing list is managed by
    majordomo@bitmover.com and is called bitkeeper-users). Everyone is
    welcome to join in and bring up their favorite gripe.

    Thanks,

    --lm

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:0.025 / U:90.736 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site