At 02:16 PM 5/1/99 -0700, Jonathan Stone wrote:
>
>In message <v6hfpwika0.fsf@kechara.flame.org>, Michael Graff writes:
>
>>Allen Briggs <briggs@ninthwonder.com> writes:
>
>>Or, how about:  ``Some ports don't have USB busses, therefore no port
>>should.''  Or beter yet, ``some machines are diskless, therefore all
>>disk support should be removed.''
>
>Those are bad analogies. If you really want an analogy, the correct
>one would be that we adopt USB support that works on i386 and Alpha
>USB hardware, but which (due to design mistakes) simply will not work
>on sparc or macppc without inordinate amounts of porting and support.
>
>Do you think NetBSD should do that? If not, why not? 
>Why is CVSup any different?

I think finally some thing has sunk in here on Jonathan, and he has finally
come up with a good analogy, and so I am going to answer him.

First lets, for the sake of discussion, stipulate that the project already runs
a sup and FTP server of suitable architecture that could run a CVSup server,
and that CVSup is *at least as efficient* as the other methods for sync up a
client.

I would assert with out proof or experience that a CVSup server can't be too
terribly hard to set up or maintain above and beyond that maintenance that the
other services would require.  Further, that there are a few people that could
not provide the machine or bandwidth, but would be willing to step up and do
the CVSup specific setup and maintenance required given a suitably net
connected machine, or on an already existing setup that currently provides the
other services.

So then it seems to me that after say 3 months 2 outcomes are possible:

a) no one, or a very few people user the new CVSup service, and it is
considered a failure.
b) lots of people do, enough that it is considered a success by those that use
it.

In case a we say ok, it was an experiment, we tried it, it was a failure, and
based on the experience we are going to terminate the experiment.  Not a big
loss.  We assumed that CVSup was at least as efficient as the other services so
we didn't hugely load the project servers or something. Those people that
didn't like the CVSup service or weren't able to use it went back to the other
methods and were no worse off than they were before the experiment.  All it
really cost us was a little time setting up the CVSup daemon and that was
donated by a volunteer.

In case b, again those that can't use the service or don't like it, go back to
their other method and are still no  worse off than before, and still it cost
the project little.  But now, the load on the project servers is much lower
since people are using the more efficient service, those that can and choose to
use the service are much happier, and people from other platforms *may* convert
over.

Seems to me that question we should be debating is not weather we should be
offering CVSup or not.  The amount of time spent on this thread alone is
probably more time than it would take to setup a CVSup daemon.  Rather the
question we should be debating is the broader question: should we as a project
make it our policy that all project progress has to come on all ports equally,
or can we allow things that boost some ports if they don't damage others?

It seems to me that we already have precedence for this: UVM.  When it came
into the project IIRC it only worked on some ports, but it didn't leave the
others any worse off since they didn't have to use it.  Eventually we saw that
it was a plus and now it works on all the platforms.


--------
Christopher R. Bowman
crb@ChrisBowman.com
http://www.ChrisBowman.com/