From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3653 invoked by alias); 8 Dec 2002 23:45:29 -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 3646 invoked from network); 8 Dec 2002 23:45:28 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 8 Dec 2002 23:45:28 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18LB72-0002hO-00 for gcc@gnu.org; Sun, 08 Dec 2002 18:45:28 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18LB6y-0000Da-00 for gcc@gnu.org; Sun, 08 Dec 2002 18:45:26 -0500 Received: from ns2.jaj.com ([66.93.21.106] helo=disaster.jaj.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18LB6y-0000Cn-00 for gcc@gnu.org; Sun, 08 Dec 2002 18:45:24 -0500 Received: (from phil@localhost) by disaster.jaj.com (8.11.4/8.11.4) id gB8NjKB29756; Sun, 8 Dec 2002 18:45:20 -0500 Date: Sun, 08 Dec 2002 16:09:00 -0000 From: Phil Edwards To: Tom Lord Cc: dewar@gnat.com, gcc@gnu.org Subject: Re: source mgt. requirements solicitation Message-ID: <20021208184520.A29684@disaster.jaj.com> References: <20021208113711.8E3ECF2E46@nile.gnat.com> <200212082206.OAA19308@emf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200212082206.OAA19308@emf.net>; from lord@emf.net on Sun, Dec 08, 2002 at 02:06:31PM -0800 X-Spam-Status: No, hits=-16.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 X-Spam-Level: X-SW-Source: 2002-12/txt/msg00436.txt.bz2 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