Messages in this thread |  | | From | (Larry McVoy) | Subject | A solution for growing pains | Date | Wed, 30 Sep 1998 11:36:13 -0600 |
| |
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/
|  |