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/