Subject: Re: CVSup collections for a NetBSD CVS tree
To: Greg A. Woods <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: current-users
Date: 05/01/1999 00:06:26
In message <>,
Greg A. Woods writes:

>One man's opinion!  ;-)

Not really.  Modula-3's dominance of the sotware world is conspicuous
by its absence.

>> Surely what the NetBSD community is (and should be) aware of is the
>> truth: that if you run NetBSD, then there's a good chance that you
>> simply *can't* run CVSUp, even if you wanted to.

No, there's a good chance.  

>Yes, I know that.  It seems though that some folks think this would make
>NetBSD look bad to in some way, though I can't imagine why, especially
>since it would seem that not having CVSup even for a few platforms is
>already making NetBSD look bad to some folks (eg. me! ;-)

Look bad? No, the point is that CVSup is not a solution for NetBSD.

>> Greg, *what* entrenched user base?
>I meant that in the future tense -- i.e. the entrenched user base
>that'll exist if an equally capable alternative doesn't meet CVSup at
>the starting gate.

What on earth are you talking about here?

>>  What* benefits?

Do you have a reading disability? Like I said:

>> Right now, CVSup offers me*zero* benefits.
>So?  Does this mean you'll be first in line to port M3 to your favourite
>platform(s) so that you can benefit from it?  ;-)  Or does this just
>mean that you're not going to even think about all of this until such
>time that you do have some requirement to use CVSup?

Personally, that one utility (CVSup) doesnt offer enough for me to
make it worthwhile putting scarce cycles into porting a marginal langauge.

>> Just how is the fact that Modula-3 implementations dont exist for most
>> NetBSD ports `propaganda'? How is the fact that there are no extant
>> SRC Modula-3 ports for some of the CPU architectures NetBSD runs  `propagand
>I didn't mean that w.r.t. anything about M3.  I meant that only about
>those who've said there might be something better than the current
>implementation of CVSup, be it a re-implementation or even a new


>> The only propaganda I see is the 
>>    ``All the worlds an x86, or at least all the world I care about,
>>     so screw  *you* if you want fast, effective access to the CVS
>>     repository from other platforms''
>> message -- the one you articulate so well.
>Or alpha or m86k or sparc, all of which I run (or at least own), and all
>of which are supportable by the existing M3 compiler.  ;-)  

Not on NetBSD, though, according to the SRC homepage.

>I have a DEC
>PMAX, and potentially a vaxstation too, but I can easily make use of the
>sources I CVSup on one of the other machines via NFS or some other
>high-speed local file sharing mechanism.  I'm also almost certain anyone
>serious enough to want to use CVSup can dredge up a junk 486 or even
>pentium (especially after new years 2000!) and get NetBSD running on it
>with CVSup too.

Maybe they simply don't want to?

>> To put it more bluntly: if something better than rsync or anoncvs
>> is needed, then we *all* need it. CVSUp just is not a solution.
>Does *everyone* use SUP now?  NO!  Some folks still ftp the source tars!
>Imagine that!  Will everyone use CVSup, even if they can?  NO!  Some
>will still FTP the source tars and even the repository tars if they're
>made available, and some will still use SUP.  Is anyone seriously
>suggesting setting up a public rsync server too?  If so then some people
>will no doubt use it.

The extant CVSup implementation is not a solution because it doenst
run on all the boxes we need to support.  That is not an issue with
tar, nor ftp, nor with sup.

>CVSup is really only the solution for those folks who want a frequently
>updated local copy of some or all of the actual CVS repostitory.  

No, Greg. CVSup is *not* a solution. Please stop saying it is, because
it isn't.

>really serious third-party developers (i.e. those without CVS access) as
>well as possibly those with direct but slow CVS access will ever really
>want to use CVSup.  

So you're saying all the talk about how not having CVSup will overload
our servers and eat our bandwidth is just FUD?

>People who just track -current can still be happy
>with SUP of the head of the tree unless they want to become serious
>developers who regularly dig in and try to find and fix bugs and add new
>features and such and who feel it would be helpful to be able to see
>specific revisions and RCS logs, etc.  People who only occasionally want
>to look at a log entry or a specific delta or whatever will be more
>likely to use the annonymous CVS server, or even a CVSWeb interface if
>one is made available (which is how I look at FreeBSD stuff now that I'm
>no longer working actively with it and regularly generating internal
>releases of it for a client).

>It *could* be the better solution for folks wanting to obtain a specific
>release or branch or whatever, but it doesn't have to be the only
>solution, not ever.

No, it *could not* ``be the better solution for folks wanting'' that,
because it *isnt* an adequate solution for the NetBSD user community.

>To put it extremely bluntly:  CVSup *could* be a better solution for
>every NetBSD user that needs it if those that can't yet use it would get
>off their duffs and port M3 to their favourite platforms instead of and
>telling everyone else that they have to suffer without it too.

Greg, telling other people that *they* need to do the necessary
legwork to make your preferred (but deeply flawed, for NetBDS) tool
into a viable tool for NetBSD is both arrogant and rude.  

If you want CVSup that badly, then *you* find people with either
sufficienlty skewed taste or enough free time to do all the porting.
Or do it yourself.  But either way, please take it off this list.