At Sun, 24 Jun 2007 02:18:24 +0300, Elad Efrat wrote:
Subject: Re: CVS commit: src/sys
>
> in a large software project, where multiple people are working on
> various parts of the tree, a certain amount of coordination and
> cooperation is required to ensure -- especially to the users -- that
> the state of the tree remains stable as possible, and no one subsystem
> or design decisions step on the toes of another. in case where this is
> inevitable, a technical decision is required to choose whose toes go on
> top.
Requiring the head of the primary working branch of the source tree to
be stable and working at all times wouldn't really be an issue at all if
NetBSD were to use some different source code management tools which
facilitate this fundamental goal while at the same time not prohibiting
developers from making more experimental commits to the tree for
discussion and sharing, etc.
For example a tool such as Aegis allows for enforcement of two-phase
commits where the baseline is always guaranteed stable by the tool
itself (a change cannot reach the baseline until it has been approved
_and_ proven to work).
Other examples of distributed, collaborative, source code management
tools are Git, Mercurial (and Monotone, GNU Arch, darcs, etc.) provide
for independent creation of atomic change sets in independent
repositories which can then be merged into a common public repository.
With any of these tools a master public repository could be maintained
(mostly automatically) which only promoted working and approved changes
to each stable baseline branch of the code.
I.e. if changes are forced through any kind of two (or more) step commit
process before they can affect the stable tree used by everyone else
then this part of your argument disappears in a quite puff of smoke.
As an aside, these change-set based source code management tools, such
as Mercurial in particular, would greatly facilitate third-party
developers such as myself too. We could much more easily provide small
change sets with only inter-related changes even when our local trees
contain many un-related changes to the same files.
--
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Secrets of the Weird
<woods%weird.com@localhost>
Attachment:
pgpBlyyQwrqKn.pgp
Description: PGP signature