Subject: Re: CVSup collections for a NetBSD CVS tree
To: Greg A. Woods <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 05/01/1999 00:06:26
In message <m10dTWY-000g5pC@most.weird.com>,
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
>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.