Re: source mgt. requirements solicitation

["David S. Miller" <davem@redhat.com>]

   From: Mark Mielke <mark@mark.mielke.cc>
   Date: Tue, 10 Dec 2002 22:42:24 -0500

   On Mon, Dec 09, 2002 at 11:26:01PM -0800, Zack Weinberg wrote:
   > Linux is a large project - 4.3 million lines of code - but only one
   > person has commit privileges on the official tree, for any given
   > release branch.  No matter how good their tools are, this cannot be
   > expected to scale, and indeed it does not.  I have not actually
   > measured it, but the appearance of the traffic on linux-kernel is that
   > Linus drops patches on the floor just as often as he did before he
   > started using Bitkeeper.  However, Bitkeeper facilitates other people
   > maintaining their own semi-official versions of the tree, in which
   > some of these patches get sucked up.  That is bad.  It means users
   > have to choose between N different variants; as time goes by it
   > becomes increasingly difficult to put them all back together again;
   > eventually will come a point where critical feature A is available
   > only in tree A, critical feature B is available only in tree B, and
   > the implementations conflict, because no one's exerting adequate
   > centripetal force.
   > Possibly I am too pessimistic.
   
   Actually, the model used for Linux provides substantial freedom. Since
   no single site is the 'central' site, development can be fully
   distributed. Changes can be merged back and forth on demand, and
   remote users require no resources to run, other than the resources to
   periodically synchronize the data.

I think some assesments are wrong here.

Linus does get more patches applied these days, and less gets
dropped on the floor.

Near the end of November, as we were approaching the feature
freeze deadline, he was merging on the order of 4MB of code
per day if not more.

What really ends up happening also is that Linus begins to trust
people with entire subsystems.  So when Linus pulls changes from
their BK tree, he can see if they touch any files outside of their
areas of responsibility.

Linus used to drop my work often, and I would just retransmit until
he took it.  Now with BitKeeper, I honestly can't remember the last
time he silently dropped a code push I sent to him.

The big win with BitKeeper is the whole disconnected operation bit.

When the net goes down, I can't check RCS history and make diffs
against older versions of files in the gcc tree.

With Bitkeeper I have all the revision history in my cloned tree so
there is zero need for me to every go out onto the network to do work
until I want to share my changes with other people.  This also
decreases the load on the machine with the "master" repository.

There is nothing about this which makes it incompatible with how GCC
works today.  So if arch and/or subversions can support the kind of
model BitKeeper can, we'd set it up like so:

1) gcc.gnu.org would still hold the "master" repository
2) there would be trusted people with write permission who
   could thusly push their changes into the master tree

Releases and tagging would still be done by someone like Mark
except it hopefully wouldn't take several hours to do it :-)