This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: suggested requirement and what funding is for
- From: Mike Stump <mrs at apple dot com>
- To: Tom Lord <lord at emf dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 10 Dec 2002 13:58:49 -0800
- Subject: Re: suggested requirement and what funding is for
On Tuesday, December 10, 2002, at 12:54 AM, Tom Lord wrote:
So, what, in the free software world, does one do in such a state? I
don't know -- but I'm certainly disinclined to just throw up my arms
and walk away from it.
The usual method is to find a few unhappy users of other systems that
want/use features that their current system doesn't have, or does
poorly, and convince them to use your system. Congeal them into a user
community, with visibility into each other. Start small, one two
person teams. Treat those users well (one user cannot be that
demanding). Finish off the rough corners they find. Have them tell
two friends. Lather, rinse, repeat.
Kenner's company is exactly the type of place you need to use the
software, to bad you don't understand it. Find someone that does
understand it to help you spread arch.
From my perspective, cvs started from rcs, already popular, already in
use here and there, easy import methodology (and easy export
methodology should one want) and got into places like Cygnus (little
tiny company), and from there to hacker communities and from there into
sourceforge and the rest was history.
We won't notice arch, we'll notice that in 5-10 years arch is still
around and kicking and people are _still_ using it, then we'll consider
it.
If you have a system that can operate beside an existing system, you
could have people use arch in front of their repository to provide them
additional benefits for a decent cost. The more people that do this,
the more natural it will be for the thing just behind arch to become
arch.
Let's take a few scenarios:
Say I have an intolerably slow cvs server (I do, meta comment, it is
faster to pound on the gcc cvs server than our in-house cvs server,
despite the fact the one is across the internet and the other is
connected via a 100 mbps local connection), say I could say:
arch co backed-by:cvs:gcc.gnu.org:/cvs/gcc gcc
and then:
arch update, arch diff, arch ci, arch merge...
and have all these operations be blindingly fast. Maybe I would want
to use arch, even though, I could not use arch, because my central cvs
server is just a hair beyond my control.
Maybe you haven't made that work yet, or maybe you've not told me that
it works.
Maybe people have an overloaded cvs server that is very slow on
branches and they now have tons of extra branches now that they never
had before. Maybe arch could be plugged into the server on the side of
cvs, with cvs commits triggering arch pull commands and arch commits
going into cvs directly. The people on branches start using arch,
because, well, it just kicks butt compared to cvs. Then maybe a few
other users start using it because they can manage their local changes
better with all the extra neat merging functionality and ease of use
arch provides. Maybe over time, people just turn off the cvs part, as
no one uses that `side' of it anymore.
Find one user willing to try arch, and make him happy. Then find just
one more, make him happy, then find one more... Pretty soon, either
you will stop and go away, you'll have oddles of users, or you find an
equilibrium point. The best case, is find a project that will be where
gcc and Linux are today in 5-10 yaers time, and get them to use your
software. There was a time when sourceforge only had 100 projects on
it.
gcc is a large, demanding project. We'll consider arch, after 20-50
other smaller less important projects use arch for a while, and have a
good experience. arch needs users to have good experiences with it,
desite its shortcomings. Maybe you should start an I hate cvs web site
where uses can go to complain about cvs, and then find users from that
pool.
Certainly there were shortcomings with cvs, but they were overlooked
because it offered something that rcs didn't have, that people wanted.
Free software is hard work.