From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16341 invoked by alias); 16 Dec 2002 10:16:32 -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 16333 invoked from network); 16 Dec 2002 10:16:30 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 16 Dec 2002 10:16:30 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id C620EF2E46; Mon, 16 Dec 2002 05:16:29 -0500 (EST) To: lord@emf.net, zack@codesourcery.com Subject: Re: source mgt....[_HAS_ gcc relevance] Cc: gcc@gcc.gnu.org, torvalds@transmeta.com Message-Id: <20021216101629.C620EF2E46@nile.gnat.com> Date: Mon, 16 Dec 2002 03:05:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2002-12/txt/msg00869.txt.bz2 > Well, my ideal is that changes to the mainline should occur only > _after_ they have verifiably passed all the available tests on a wide > range of platforms (a process that can be fully automated) and the > changes have passed senior engineer reviews (a process that can be > facilitated by substantial automated assistance). Mainlines should > increase in quality in a strictly monotonic fashion -- that's the > essence of what "gatekeeper management" is all about. Neither GCC nor > lk have that property -- though better tools can do much to put us > there. With good tools, the release manager can ultimately be > replaced by shell scripts. with GNAT, we let everyone within ACT, which is quite a diverse set of folks about 35 in all, change anything in the mainline, but we guarantee the monotonic properly (I agree this is crucial) by enforcing fairly strenuous requirements on anyone doing a change. No change of any kind (not even something that is "obviously" safe) is allowed without doing a complete bootstrap, and running the entire regression suite (which is pretty comprehensive at this stage) first. Now we only require this on one target for changes that are expected to be target independent, so it is possible to have unanticipated hits on other targets. We deal with this by building the system on all targets every night and running the regression suites on all targets every night. If the reports in the morning indicate a problem, then it is all hands on deck to fix the problem. When we get GNAT properly integrated into GCC, which involves several things still to be done: 1. We need to get to a release point internally where the GCC 3 based GNAT passes all regression tests etc. We are close to this, and expecting to do a beta release in January on selected targets (should include Solaris, Windows, GNU/Linux, HPUX). 2. We need to get the sources and our internal source procedures more amenable to GCC style (e.g. we have removed the version numbers from our sources, and adjusted all our scripts for this change recently). 3. We need to establish the ACATS test suite so that anyone can run it. This is not as comprehensive as our internal test suite (which is not distributable since it is mostly proprietary code). 4. We need to set up procedures so we can run and test changes that others make against our internal test suite. ... then hopefullly we can duplicate at least some of these procedures in a manner that others outside ACT can follow a similar path. We regard this kind of automatic testing as absolutely crucial. > With good tools, the release manager can ultimately be > replaced by shell scripts. I don't believe that, based on our experience where we have elaborate scripts that try to automate everything, but you still need a release manager to coordinate activities and check that everything is working as expected.