source mgt. requirements solicitation

[Tom Lord <lord@emf.net>]

       dewar:
       > No, it is just the entire style of your presentation.

Ok, here's a patch:


       > In fact CM and revision control systems are quite critical to
       > many of our customers. We have several customers managing
       > systems with tens of thousands of files and millions of lines
       > of code.
       [...]
       > Perhaps you are missing an opportunity here
       [...]
       > if the intent of this thread was to encourage people to look
       > at arch, it has not worked with me.

I'm inexperienced in sales, but from what I read, the right thing here
is for me to solicit from you much more information about what you
think your (or your customers) needs are -- then if `arch' fits, I can
state why in your terms (and if not, thank you for your time and take
my leave).  Ok?

So, I'm listening.  For both the GCC project and ACT's customers, what
do you (and others on this list) initially think is important in
source management technology, especially, but not limited to revision
control and adjacent tools?

I said "initially" because I'm wondering how to proceed if you list
requirements that I think are buggy in one way or another.  Is it
"good style" to point that out if it occurs?

I encourage you to spend a little time answering these questions.
There are currently three of four serious revision control projects in
the free software world (OpenCM, svn, arch, and metacvs), all in the
later stages of initial development.  A lot of people, besides just
me, can probably benefit from your (and other GCC developers') input
-- and your input can help make sure you get better tools down the
road.

I have some observations that I hope your answers might begin to
address.  These are observations of facts I think are relevant; I'm
assuming it's "good style" to stop there rather than to try to turn
these into leading questions.  These observations include (in no
particular order):

	1) There are frequent reports on this list of glitches with
	   the current CVS repository.

	2) GCC, more than many projects, relies on a distributed
           testing effort, which mostly applies to the HEAD revision
	   and to release candidates.  Most of this testing is done
	   by hand.

	3) Judging by the messages on this list, there is some tension
	   between the release cycle and feature development -- some
	   issues around what is merged when, and around the impact of
	   freezes.

	4) GCC, more than many projects, makes use of a formal review
           process for incoming patches.

	5) Mark and the CodeSourcery crew seem to do a lot of fairly
	   mechanical work by hand to operate the release cycle.

	6) People often do some archaeology to understand how
           performance and quality of generated code are evolving:
	   they work up experiments comparing older releases to newer,
	   and comparing various combinations of patches.

	7) Questions about which patches relate to which issues in the
	   issue database are fairly common.

	8) There have been a few controversies from GCC "customers"
           arising out of whether they can use the latest release, or
	   whether they should release non-official versions.

	9) Distributed testing occurs mostly on the HEAD -- which
           means that the HEAD breaks on various targets, fairly
           frequently.

	10) The utility of the existing revision control set up to 
	    people who lack write access is distinctly less than 
	    the utility to people with write access.

	11) Some efforts, such as overhauling the build process, will
	    probably benefit from a switch to rev ctl. systems that
	    support tree rearrangements.

	12) The GCC project is heavily invested in a particular
            testing framework.

	13) GCC, more than many projects, makes very heavy use of 
	    development on branches.

-t