From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15735 invoked by alias); 27 Mar 2002 07:53:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15689 invoked from network); 27 Mar 2002 07:53:22 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by sources.redhat.com with SMTP; 27 Mar 2002 07:53:22 -0000 Received: (from lord@localhost) by emf.net (K/K) id XAA03892; Tue, 26 Mar 2002 23:53:21 -0800 (PST) Date: Tue, 26 Mar 2002 23:53:00 -0000 From: Tom Lord Message-Id: <200203270753.XAA03892@emf.net> To: dan@dberlin.org CC: gcc@gcc.gnu.org, gdb@sources.redhat.com In-reply-to: (message from Daniel Berlin on Wed, 27 Mar 2002 02:10:52 -0500 (EST)) Subject: Re: gcc development schedule [Re: sharing libcpp between GDB and GCC] References: X-SW-Source: 2002-03/txt/msg00275.txt.bz2 Dan: Because it causes things to stagnate on branches, while attempting to meet the "high barrier" on the trunk. Not necessarily. It depends on your tools. For this issue, the relevant tools are the testing infrastructure and revision control infrastructure. Regarding testing, there seems to be two shortfalls. One is in the completeness of the existing test suite: at least one vendor finds it necessary to supplement that test suite with tests they buy a license for in order to obtain better coverage; beefing up the test suite would give more developers more direct access to more thorough testing. The other issue is automation. There are at least two instances of vendors implementing their own infrastructures to grab the head from the trunk and test that periodically in various ways (and I suspect that there are, in fact, several more than two); a better approach would be to collect those automated testing infrastructures under a common (automated) interface and make them available to lots of branches (even branches not maintained by people with write access to the main repository). Regarding revision control, there can be a queue from branches (including branches outside the main repository) to the trunk. For most change sets, propagation along that queue, passing through the testing barrier, can be automated. BitKeeper seems to be up to that already. arch and Subversion are both close behind. Even where you might want to inject a human conducted review into the queue process, tools infrastructure can help simplify that process and reduce the reviewer's action from "check in these changes" to "click the thumbs-up/down button". In addition, it assumes there is no overhead associated with maintaining a branch (and let's not get into a discussion about arch or anything Actually, I've been trying to avoid the topic of merging tools precisely because the issue is bigger than arch. Yes, I think arch can be a big help here -- but so, perhaps, can Subversion or BitKeeper. Heck, there's even a GCC maintainer who contributes to Subversion. If the discussion ever reaches the stage of contemplating choices of revision control system, I'll be happy to help make the case for arch. At this stage, in this context, it's probably not important. Sorry, but nobody is going to merge a complete rewrite of the C++ parser, for instance, to the head, without *any* difficulties whatsover. Using _any_ modern system, the merge can be worked out on a branch and the transition to the trunk automated. One advantage of "hierarchical software management" is that it allows difficult merge instances to be distributed down the hierarchy -- making it easier for more than just maintainers with write access to work on them. Core maintainer bandwidth can be _increased_ by effective branching, in contrast to the expectation expressed there and elsewhere in your message. -t