From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3545 invoked by alias); 12 Sep 2004 18:36:37 -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 3538 invoked from network); 12 Sep 2004 18:36:36 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 12 Sep 2004 18:36:36 -0000 Received: from zaretski (pns03-197-237.inter.net.il [80.230.197.237]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CNT05734 (AUTH halo1); Sun, 12 Sep 2004 21:36:08 +0300 (IDT) Date: Sun, 12 Sep 2004 18:36:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c498f7$Blat.v2.2.2$53c9e1a0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: kettenis@gnu.org, brobecker@gnat.com, gdb-patches@sources.redhat.com In-reply-to: <41448FBF.50009@gnu.org> (message from Andrew Cagney on Sun, 12 Sep 2004 14:04:47 -0400) Subject: Re: [patch] Deprecate XM_FILE and TM_FILE Reply-to: Eli Zaretskii References: <413898FB.7080502@gnu.org> <01c49276$Blat.v2.2.2$c81daa00@zahav.net.il> <4139D06B.5060902@gnu.org> <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> <413A277E.3060700@gnu.org> <01c492ff$Blat.v2.2.2$4fec0480@zahav.net.il> <41407F45.2090401@gnu.org> <01c496a3$Blat.v2.2.2$8948c5e0@zahav.net.il> <4140BC4C.50003@gnu.org> <01c496b2$Blat.v2.2.2$22c509a0@zahav.net.il> <20040909212638.GI5843@gnat.com> <01c49718$Blat.v2.2.2$de0204a0@zahav.net.il> <200409101241.i8ACfUHq027340@juw15.nfra.nl> <01c49753$Blat.v2.2.2$b39e6b00@zahav.net.il> <41448FBF.50009@gnu.org> X-SW-Source: 2004-09/txt/msg00200.txt.bz2 > Date: Sun, 12 Sep 2004 14:04:47 -0400 > From: Andrew Cagney > Cc: Mark Kettenis , brobecker@gnat.com, > gdb-patches@sources.redhat.com > > I think this debate is over the point at which something can be deprecated. It's about a point where something can be deprecated, and also about the conditions that should be fulfilled for that. > For GDB, as soon as we've got the new mechanism up and running - > confirming its ok - we're going to draw a line and deprecate the old > mechanisms. We're not going to require that every single detail of > every single dependant variant also be addressed. I don't know about ``we'', but as far as I'm concerned, I cannot approve a patch that deprecates XM_FILE as long as the 3 defines in xm-go32.h are not set by an alternative non-deprecated mechanism. > > We can easily do that (and actually do that) by rejecting patches that > > use the old mechanism. > > We don't. Yes, we do. You can find examples of that in the archives, including messages by yourself. > In the past, requests to not use old mechanisms have been [er] > declined If such a request is declined, we can reject the patch. I don't see a problem here. Anyway, this is all have been beaten to death in this thread, we are just reiterating the same issues again and again. I already suggested a constructive (IMHO) approach, and I don't have anything new to add to it.