Subject: Re: CVSup collections for a NetBSD CVS tree
To: None <email@example.com>
From: Miles Nordin <carton@Ivy.NET>
Date: 04/26/1999 23:04:11
On Mon, 26 Apr 1999, Thor Lancelot Simon wrote:
> It's a waste of our time to put much effort into setting up servers for a
> service a very large portion of our user community can't use
and a bad precedent.
that some of the servers would benefit from CVSup, and others would have
an alternative, isn't a sufficient argument.
CVSup, anoncvs, and sup are tools that sit at the center of our community,
since everyone participating in (or even observing) NetBSD's development
ends up at least _trying_ to use them.
The recent Slogan Wars revealed some of the project's long-standing
Clearly, NetBSD is The Only UNIX that has aspired toward the quality of
early academic UNIX code, which existed to facilitate collaboration,
experimentation, new ports, u.s.w.--in short, the NetBSD source code, in
the absence of any specific physical hardware to run it on, has value.
And, that which actually _does_ run on something is not merely a useful
tool, but an example of how to write good code, an inspiration, and a
piece of history.
Achieving this type of code in the bewildering short-attention-span
theater of today's available programming talent requires that new NetBSD
contributors be ruthlessly, painfully, and subtly indoctrinated toward
the True UNIX Ideology.
NetBSD, therefore, can't afford to have ``favorite'' architectures. Even
if we accept that CVSup is _functionally_ superior (which must balance
against the maintenance and bug-tracking burden of solving the same
problem twice) the ideological pollution of potential new developers is an
o solve each problem _once_.
o if offered two bad alternatives, choose the one sitting on the
CVSup's contribution should therefore be confined to a reinforcement of
the comments made at the end of CVS's client-server protocol reference
manual: there is room to further optimize the protocol. The CVS document
mentions a couple specific ideas, and perhaps the CVSup protocol has a few
more to add.
I read that document, and Per's CVS manual, _because_ NetBSD's site
said, ``use CVS and sup to track -current with local changes.'' I'm rather
glad I wasn't lead into using some Pascal program that runs exclusively on
AIX and interfaces with Informix and has a Motif GUI, instead of CVS. I
get enough of that brute-force-development nonsense at work.
For NetBSD, conspicuously _not_ using CVSup serves the project better.
A rehash of existing arguments:
NetBSD maintains and routinely assimilates ports to dead or dying
architectures. That NetBSD can afford to add a port just because someone
thought it'd be fun, or someone needed it for an embedded project, is a
curiously deliberate accomplishment. These little ``fun'' ports stick
around forever--they can succeed only by keeping their maintenance needs
within the bounds of a sometimes minimal interest.
The project facilitates meeting this requirement by keeping that which is
architecture-dependent small, clean, maintained by a responsible person,
and intimately integrated.
Modula-3 is big, probably dirty, insufficiently interesting to justify its
gargantuan maintenence needs on all existing and future ports (think:
sh3), and poorly integrated with NetBSD--that is, it's used by only one
relatively superficial proposed package.
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700