From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31763 invoked by alias); 8 Dec 2002 22:09:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31756 invoked from network); 8 Dec 2002 22:09:58 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 8 Dec 2002 22:09:58 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18L9cc-0001Sl-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:09:58 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18L9ZK-0002NH-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:06:35 -0500 Received: from emf.emf.net ([205.149.0.20] helo=emf.net) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18L9ZJ-0002N3-00 for gcc@gnu.org; Sun, 08 Dec 2002 17:06:33 -0500 Received: (from lord@localhost) by emf.net (K/K) id OAA19308; Sun, 8 Dec 2002 14:06:31 -0800 (PST) Date: Sun, 08 Dec 2002 14:18:00 -0000 From: Tom Lord Message-Id: <200212082206.OAA19308@emf.net> To: dewar@gnat.com CC: gcc@gnu.org In-reply-to: <20021208113711.8E3ECF2E46@nile.gnat.com> (dewar@gnat.com) Subject: source mgt. requirements solicitation References: <20021208113711.8E3ECF2E46@nile.gnat.com> X-Spam-Status: No, hits=-4.6 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_05_08 version=2.41 X-Spam-Level: X-SW-Source: 2002-12/txt/msg00430.txt.bz2 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