This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
suggested requirement and what funding is for
- From: Tom Lord <lord at emf dot net>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 10 Dec 2002 00:54:24 -0800 (PST)
- Subject: suggested requirement and what funding is for
I'd like to suggest a few more requirements for your next revision
control system:
* Simplicity.
Very large and complex tools simply aren't needed for revision
control.
* Formal Specification
Critical elements, such as change set formats, network protocols,
and repository formats deserve formal specification. This is
for at least three reasons:
A) Revision control sits adjacent to many other tools and
their possibilities for inter-operation determine how
easily processes can be automated. Formal specifications
enable robust inter-operation.
B) Revision control has (very long term) _archival_,
_cataloging_, and _accessibility_ responsibilities. Formal
specification of all of the file and directory formats
involved enhances its value in these areas.
C) Formal specification is essential to thorough testing
of this very critical tool.
* Multiple Implementations
Multiple implementations help to establish that the system is indeed
simple and formally specified. For that and other (obvious)
reasons, they also help to reduce the risk of your choice.
So, what is funding for? Why not just rely on volunteers to hack arch
until it's done and "proven" by grass-roots adoption?
arch currently exists as a useful and functional prototype, exhibiting
nearly all of the ultimately desired functionality, but with many
minor problems. Some problems are obvious: As Walter mentioned,
_some_ commands are too slow. I've mentioned a few known bugs in my
replies.
Some problems are less obvious: the formal specs haven't been written
(started, but not written). There isn't a test suite derived from
those specs.
With funding, and a small team, we can finish 1.0 The Right Way,
fairly simply: tasks such as formally specing the changeset format
(making the design changes we know are needed), implementing a test
suite, and then, _after_ those steps, making the necessary changes to
fix performance and other bugs.
That's not the kind of work volunteers seem to be attracted to doing.
I also will defend the claim that it is very straightforward work, and
that my 6-engineers/1-year/$1.2M estimate is a reasonable one.
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.
Regards,
-t