From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27015 invoked by alias); 13 Sep 2004 19:48:19 -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 26999 invoked from network); 13 Sep 2004 19:48:18 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 13 Sep 2004 19:48:18 -0000 Received: from zaretski (pns03-194-44.inter.net.il [80.230.194.44]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DUG78153 (AUTH halo1); Mon, 13 Sep 2004 22:48:09 +0300 (IDT) Date: Mon, 13 Sep 2004 19:48:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c499ca$Blat.v2.2.2$8aaaa820@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: <4145BDB1.6010601@gnu.org> (message from Andrew Cagney on Mon, 13 Sep 2004 11:33:05 -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> <01c498f7$Blat.v2.2.2$53c9e1a0@zahav.net.il> <4145BDB1.6010601@gnu.org> X-SW-Source: 2004-09/txt/msg00213.txt.bz2 > Date: Mon, 13 Sep 2004 11:33:05 -0400 > From: Andrew Cagney > Cc: kettenis@gnu.org, brobecker@gnat.com, gdb-patches@sources.redhat.com > > > It's about a point where something can be deprecated, and also about > > the conditions that should be fulfilled for that. > > I think this is progress, this discussion is finally focusing in on > specific concerns. This was my intent from the beginning. I'm glad that I finally succeeded in explaining myself. > >>> 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. > > That is deprecation. > > For us to reject such a patch we must have clearly, explicitly and > formally identify the mechanism as one that should not be used, and > recorded the decision in a way that both the patch reviewer and > contributor can quickly and efficiently access. Fine. All I ask for is to record the deprecation fact somewhere other than in the code, until the 3 definitions are converted to use some better mechanism.