From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32098 invoked by alias); 22 Aug 2003 15:32:32 -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 32090 invoked from network); 22 Aug 2003 15:32:32 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 22 Aug 2003 15:32:32 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6E4512B7F; Fri, 22 Aug 2003 11:32:31 -0400 (EDT) Message-ID: <3F46378F.1000102@redhat.com> Date: Fri, 22 Aug 2003 15:32:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [commit] Last major piece of fork tracing - vfork/exec References: <20030817201922.GA10584@nevyn.them.org> <3F40F4BF.5020702@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00389.txt.bz2 >> This patch is the last major piece of fork tracing: support for vfork and >> exec. I have not enabled the code in infrun which attempts to automatically >> load the new executable, because I'm not happy with how it works, and >> because it isn't necessary for this to be useful. >> >> I'll move this to the branch in a day or two if there are no problems. >> I suppose fixing up the expected output in the testsuite is next... >> > Please don't. The only things I know of still going down for 6.0 are some testsuite mangling and a re-fix for the red zone. > > Anything else can go in 6.1. > > My core file stuff, for instance, isn't in 6.0. Daniel, I'm really disappointed by the situtation you've created here. You, by at the last moment trying to add this new functionality to 6.0 branch, have effectively pushed me into a corner. I've got the following choices: - yank the existing code invalidates relevant tests as the release manager, I get the blame for delaying both the new feature and the release - leave the code as is Again, I get the blame for the feature not being present (after all it is just wafer thin and won't have any affect on all the test results that people have been doing up-until now, right?) - let the change in invalidating test results again delay the release ... Against my better judgment, I've decided to go with option 3. You can commit this change but the release is delayed an extra week. I'm now also forced to consider a move away from self regulation and instead require release manager approval for all branch changes. A change that would benefit no one :-( Andrew