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
definitive goals.

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
intolerable sacrifice.

 o solve each problem _once_.
 o if offered two bad alternatives, choose the one sitting on the 
   good path.

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