Re: source mgt....[_HAS_ gcc relevance]

[Zack Weinberg <zack at codesourcery dot com>]

Tom Lord <lord@emf.net> writes:

> In relation to these features, it's interesting to read the recent
> narrowly-on-topic traffic on the gcc list (Mark and Zack's
> coordination with everyone else, comments about forming intermediate
> merges, and calls for help with testing branches).  I think that some
> of the issues around synchronizing work would be somewhat relaxed by
> applying these features; intermediate merges would be well
> facilitated and _partially_ automated (regardless of access writes of the
> authors); testing branches could be made more effectively
> automated (again, orthogonally to access rights).

Oh, no kidding.  I totally agree that a distributed repository system
is the way to go long term, and you'll notice that easy branches was
close to the top of my requirements list.

My comment about the Linux kernel development process was intended as
a comment about the way that project operates, which I happen to have
concerns about, but I'm pretty sure that's the way it has always
operated, independent of version-control system in use.

Linus Torvalds <torvalds@transmeta.com> writes:
> Many people want to check stuff into the CVS tree _not_ because they
> really want everybody to see the thing, but because they use the CVS tree
> as a way to communicate with a few other people working on the same thing.
> That's where the "single main repository" _really_ falls down.

And this is the assumption underlying the part of the kernel process
that I have concerns about.  It's true that mostly only a small number
of people work on any given chunk of a large piece of software, but I
strongly disagree that they should go off by themselves and merge into
the main tree only when they're done, as the default mode of
development.  The effect from everyone else's point of view is that
they pop up and inflict a huge indigestible glob of code on everyone,
which invariably has not been tested thoroughly enough and breaks
stuff.  Just watching linux-kernel suggests that this happens all the
time.  The USAGI patches, for instance, or Rusty's module rewrite.
We've had our share of this in GCC, too; the 'subreg_byte' changes
were maintained at enormous effort separate from the main tree for
_years_ before they accumulated enough evidence that it wouldn't break
anything.

Contrariwise, forcing people to do their work in the main tree means
that they have to do it incrementally, more eyes at least skim the
code, and it naturally gets adequate testing as other people try to do
their own work.  Also, I know that every time I've had to stop and
think how to do a transition incrementally, the end result has been
better off for it.  Al Viro's rewrite of the VFS layer is the obvious
example of this, or Jan Hubicka's jump optimizer overhaul.

As a user of the kernel, I am also concerned about the apparent trend
toward having many variant trees not for development, but to present
divergent sets of features and bugfixes.  It strikes me as a recipe
for user confusion and vendor malfeasance.

zw