> The mere fact that NetBSD users and developers seem afraid of this tool
> makes me scream!  ;-)

Refering to those who oppose the parallel deployment of anoncvs and CVSup
as ``afraid,'' to put it kindly, obscures our arguments.  I would
appreciate it if you (and others) would confine your discourse to
addressing those arguments and presenting new ones.

I find the supposition, even in jest, that your opponents do not agree
with you because they are ``afraid'' of your ideas, at least mildly
insulting.  Also, it is inacurate, or at the very least a deceptive
oversimplification.

> Not all NetBSD ports are treated as equal.  I challenge anyone
> claiming this to obtain at least one, and possibly two, machines in
> every supported architecture and to use all of those machines on a
> daily basis and to dilligently upgrade each machine to the latest
> NetBSD software every time.

> You'll find so many differences, discrepancies, etc., that you'll
> probably start pulling your hair out

I think it's obvious that you're being unreasonable here. Forgive me for
having no sense of humor, but it seems that the difficulty of obtaining
obscure hardware and the improbability of finding something useful to do
on ninteen different machines in a single day has little to do with
NetBSD's efforts to become and remain platform-independent.  I see that
you have a potential point here, but I think the hyperbole weakens your
argument if anything.

I've found the experience of performing regular (about every two weeks,
according to my CVS logs) builds on sun3, sparc, and alpha mellow enough
that i consider the acquisition of new hardware without regard for its
platform.  I think this is one of NetBSD's key visions (ref: Slogan Wars).
In all fairness, i'm somewhat of an enthusiast and junk-collector in this
regard, meaning that i would probably _prefer_ to have an Atari Falcon
rather than another sun3.

Granted, platforms necessarily differ, in booting for example, and in many
kernel drivers.

A more reasonable challenge:  find a piece of userland code in NetBSD's
src tree that builds on one platform, but does not on another.  I have yet
to encounter one, but perhaps they do exist.

I suspect that if you do find one, it will be either (a) a bug that the
portmaster would acknowledge and feel warrants semi-immediate attention,
or (b) part of an ongoing effort like wscons or the ELF toolchain to
maximize code reuse between architectures.

This demonstrates one of NetBSD's key goals, one of the characteristics
many of us are proud of (ref: the Slogan Wars again).  I believe this goal
and its underlying philosophy have some incredibly desireable and uniquely
exciting consequences, which I addressed in my earlier post.

To provide an infrastructure feature from netbsd.org that only some
platforms can use bucks this whole philosophy.  TNF should not endorse a
package that favours one architecture over another: not by importing it
into src, not by setting up servers for it.  

To do so is demoralizing to those enthusiastic about this key idea of
platform independence. It gives a confusing message to new developers and
enthusiasts.  It encourages similar laziness in future projects: ``it only
works on i386 for now--that's a start, and good for those with i386's.  
We'll work on portability later.'' No!  this is more work in the long run,
and definitely it's ideologically disasterous.  Again I'm being brief
because i've expressed the indoctrination/Jedi Cult argument several times
already.

However, I can provide another example of our philosophy's benefit.  
Compare NetBSD's portability with the mess that is Linux.  I was finally
pushed to commit to NetBSD after spending three months fighting with
Linux's FreeBSD-derived aic7xxx driver, which supported my board on i386
but not on alpha.  Doug Ledford's primary concern seemed to be supporting
the undocumented bugs that crop up in (disgustingly frequent) new
revisions of the Adaptec chips soldiered onto the boards of various Dell's
and Gateway's.  He presumably wanted RedHat to compete with Windows NT's
Adaptec-written drivers, at least on RedHat's ``favorite architecture,''
rather than fixing messiness in the code.  Consequently, I wasn't stuck
with the wrong revision of a buggy board that i could replace, but rather
with a perfectly bug-free CPU made by the less-favoured company:  technical
superiority eschewed in favour of the Invisible Tentacle of capitalism.  
From my Linux/Alpha nightmare, I can site other examples of how RedHat's
Wintel bias went hand-in-hand with poor coding.  But, again, I refer you
to my earlier post because this discussion only begins to explore the
value of NetBSD's portability imperative.  There is further value to it.


You've already stated your intent to create a private CVSup server, and I
believe wosch already has one at cvsup.de.freebsd.org. That's a great
idea, but I think the endorsement of the central NetBSD infrastructure is
too influential to consider only utilitarian goals.

The power of TNF's endorsement role should not be underestimated.  They
provide the project's key infrastructure, and they definitely promote a
specific philosophy, more so than any other OS I've seen.  This philosophy
pervades their entire work.  It always does, in any organization, on any
project.  It's NetBSD's single greatest asset.


If CVSup's author wanted to maximally respect the earlier work upon which
CVSup is based, and to be of the greatest possible benefit to the 'net
community, he would have contributed his ideas and coding to the CVS
project.  Certainly this is not the only legitimate reason to write code,
but I believe this ideology is central to NetBSD.  Using and importing a
package means using and importing its ideology, too, and CVSup is poor in
that respect.

From what I'm hearing, CVSup sounds like an exciting demonstration of good
computer science.  I can understand the feeling of seeing something you
always imagined was an impractical dream (ex. Coda, H-PFQ), crystallized
into reality, into code you can build, inspect, and execute. I do not want
to diminish CVSup's contribution--the way it has optimized the
``minimize-rtt's, send only delta'' idea, the critical ``local branch''
concept--but for NetBSD, it's useful contribution is limited to these
valuable ideas.  The code itself shouldn't be used.

The other value of CVSup to NetBSD is in its conspicuous rejection:  for
users to understand _why_ CVSup, in spite of its technical elegance,
cannot be endorsed as a portal to the official central CVS tree.


Where to go from here is an open question.
  o tolerate the inefficiency of anoncvs, and focus our attention 
    somewhere more relevant
  o petition/assist Modula-3 enthusiasts with porting their code, 
    or transforming it into an egcs frontend, which Cygnus would
    likely accept given their existing Chill and Java frontends
  o use the ideas of CVSup as an inspiration for the improvement
    of CVS's client-server protocol, or even local branch support

I don't see forking the CVSup project into a different language as a 
worthy expenditure of energy, and I see TNF endorsement of CVSup 
as not only an unreasonable drain of their resources, but a _loss._

My own opinion: 
The scale of a hypothetical Modula-3 porting project is out-of-line with
the benefit of more efficient source updates.  It's an interesting
project, but it should be considered for what it is: an interesting
project, not an answer to NetBSD's CVS distribution need.

We've got some good ideas for the improvement of CVS, and perhaps a
testimony toward the potential value of Modula-3.  But, reasons to reverse
TNF's decision to use anoncvs exclusively, we have not.


Arguments on the basis of indoctrination, philosophy, gestalt are
difficult to make, difficult to follow, and difficult to counter.  I'm
spending so much time on this because I believe such arguments are
tremendously relevant to the future and past of the project, and that we
should therefore endure their inconvenience.  This is the core of the
discussion, right here:  where to direct our efforts, how to preserve and
enhance that which we value.  NOT how to find a compromise that pleases
the greatest number.  _I_ could use CVSup, yet I want _not_ to have it.

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700