Re: CVS, Linus, and us

Keith Mason (kamason@robots.com)
Thu, 22 Feb 96 16:17:53 PST


> Certainly. I didn't want to imply that we should (or could) force Linus to
> do anything. Anyway, Linus's original thoughts on the topic are tagged on
> down below for those of you who missed it the first time (1.3.45 era).

Linus:
> I'd be more than happy to make some easy change logging facility
> available, but I'm afraid that I don't like the idea of having
> developers do their own updates in my kernel source tree.
>
> I know that's how others do it, and maybe I'm paranoid, but there really
> aren't that many people that I trust enough to give write permissions to
> the kernel tree.. Even people I have worked with for a long time I want
> to have the option of looking through their patches _first_, and maybe
> commenting on them (and I do reject patches from people).

How about this: One person creates and exports an official CVS tree that
development is *not* performed on. The tree is strictly for the purpose
of being able to apply patches between different releases.

So if I have kernel 1.3.45, with a patch to fix a problem, and I know the
problem is not fixed in 1.3.67, I can simply do a cvs update of my current
checkedout revision to apply all of the changes between 1.3.45 and 1.3.67
so that I may submit it to Linus in a state he can use it by simply executing
a cvs diff.

This would also allow people to be able to maintain their own local patches
that should not be applied to the public sources, without having to unpatch
update and repatch (and try to figure out which hunks failed and why).

Then, if and when Linus decides that CVS is a Good Thing, he can take over
maintaining the CVS tree. But the tree is read-only for everybody but the
maintainer.

This is very easy to do (after creating the CVS repository in the first
place), because the CVS tree is made available via FTP or NFS or whatever
in a read-only state.

It would be a Bad Thing to allow any untrusted people write access to the
CVS repository because it is very easy to screw up if you don't know what
you are doing (not that it's hard, but if the maintainer is using tags to
separate releases, somebody can easily wipe a tag out of a complete tree
or delete important revisions with no easy way to undo it). And as long
as only one person is applying patches to the official code anyway, then
only that one person should be allowed to change the repository.

-- Keith