This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]