A solution for growing pains
Larry McVoy
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
majo...@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 majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Larry McVoy
: interested in this topic, please visit http://www.bitmover.com/bitsccs
Oops. That's the low level page. The higher level stuff is described
on the bitkeeper page, http://www.bitmover.com/bitkeeper .
Eric S. Raymond
> That's probably enough hand waving for the moment.
I've been thinking along rather similar lines (though not with specific
reference to bitmover). I think I'm already on the bitmover list.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>
The following is a Python RSA implementation. According to the US Government
posting these four lines makes me an international arms trafficker! Join me
in civil disobedience; add these lines of code to your .sig block to help get
this stupid and unconstitutional law changed.
============================================================================
from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
'-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))
It will be of little avail to the people, that the laws are made by
men of their own choice, if the laws be so voluminous that they cannot
be read, or so incoherent that they cannot be understood; if they be
repealed or revised before they are promulgated, or undergo such
incessant changes that no man, who knows what the law is to-day, can
guess what it will be to-morrow. Law is defined to be a rule of
action; but how can that be a rule, which is little known, and less
fixed?
-- James Madison, Federalist Papers 62
Kevin Fenzi
Larry> Oops. That's the low level page. The higher level stuff is
Larry> described on the bitkeeper page,
Larry> http://www.bitmover.com/bitkeeper .
Just as a side note, has anyone looked at Aegis?
It appears to do at least some of these things already...
http://www.canb.auug.org.au/~millerp/aegis.html
Note that I haven't used it, but I noticed a announce for it, and
thought it might be worth looking at...
kevin
--
Kevin Fenzi
ke...@scrye.com
http://scrye.com/~kevin/