source mgt. requirements solicitation

[Phil Edwards]

On Sun, Dec 08, 2002 at 02:06:31PM -0800, Tom Lord wrote:
> 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?

It's more likely that they understand the requirements better than you do,
so it would be /better/ style if you said, "could you elaborate on this,
here are my questions," rather than, "no, /your/ requirements are buggy."


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

IIRC, these have all been caused by non-CVS problems.  (E.g., disks filled
up, mail server getting hammed and DoS'ing the other services, etc.)


> 	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.

I'll borrow one of your choice phrases and call this a bullshit rumor.
It's nearly all automated.


> 	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.

Yes.  I don't see how the choice of revision control software makes a
difference here.  The limiting resource here is people-hours.


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

Yes.

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

Perhaps you haven't looked at contrib/* and maintainer-scripts/* lately?
Releases and weekly snapshots are all done with those.


> 	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.

Yes.  This is also automated, e.g., Diego's SPEC2000 pages.

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

*shrug*  When a patch is committed with an PR number in the log, the
issue database takes notice of it.  That's something that we added with
a CVS plugin.


> 	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.

Yes.  What does this have to do with revision control software?  Anybody
using open source can make this same decision.

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

Uh, no.  Exactly backwards.

> 	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.

Well, duh.

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

Probably.

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

Yes.  Well, that plus the new QMtest, which looks to bo far superior.

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

Yes.


-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002