From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20931 invoked by alias); 29 Nov 2002 16:18:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20785 invoked from network); 29 Nov 2002 16:18:33 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Nov 2002 16:18:33 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gATFrsP20599; Fri, 29 Nov 2002 10:53:54 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gATGIVD14077; Fri, 29 Nov 2002 11:18:31 -0500 Received: from north-pole.nickc.cambridge.redhat.com.redhat.com (vpnuser1.stuttgart.redhat.com [172.16.4.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gATGIRC03841; Fri, 29 Nov 2002 11:18:29 -0500 To: ac131313@redhat.com, neroden@twcny.rr.com Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com, gcc-patches@gcc.gnu.org Subject: Re: (toplevel patch) Remove 'vault' targets References: <20021128024607.GA14747@doctormoo> <3DE59B7C.10205@redhat.com> <200211280501.gAS519S00664@envy.delorie.com> <3DE65CE4.5020908@redhat.com> <3DE78612.6070603@redhat.com> From: Nick Clifton Date: Fri, 29 Nov 2002 08:18:00 -0000 In-Reply-To: <3DE78612.6070603@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00740.txt.bz2 Hi Andrew, > >> M'kay by me. Nick? Preference? > > I would prefer to keep the two projects in sync if possible. I > > assume > > that there is no great urgency to remove the vault targets, so why not > > wait until the gcc freeze is over and the patch can be applied to both > > projects at the same time ? > > If it were a single patch, it would be no big deal. Unfortunatly, it > is an accumulating sequence of changes that will hit GDB/BINUTILS at > some random point in the future (most (all?) patches that > Nath. recently posted are being parked on a branch :-(). > > In the case of GDB, mega-jumbo breaking branch merges are not our > style. Nath. would effectively have to slow-mo re-play these changes > into the src repository :-( In which case, Nath - please go ahead and apply the patches. Cheers Nick