From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29761 invoked by alias); 24 Sep 2004 22:06:22 -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 29552 invoked from network); 24 Sep 2004 22:06:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Sep 2004 22:06:14 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8OM69TP020961 for ; Fri, 24 Sep 2004 18:06:09 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8OM63r26185; Fri, 24 Sep 2004 18:06:03 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C939128D2; Fri, 24 Sep 2004 18:03:46 -0400 (EDT) Message-ID: <415499C2.4010203@gnu.org> Date: Fri, 24 Sep 2004 22:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Joel Brobecker Cc: Eli Zaretskii , kettenis@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [patch] Deprecate XM_FILE and TM_FILE References: <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> <01c499ca$Blat.v2.2.2$8aaaa820@zahav.net.il> <41460B78.90005@gnu.org> <20040913213015.GC5843@gnat.com> In-Reply-To: <20040913213015.GC5843@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00423.txt.bz2 Joel, I almost lost this (hideing at the end of a thread) :-( Can you re-post with a new thread/subject to gdb@. I've thoughts but I'd prefer to post them there :-) Perhaps attatch eli's e-mail, or Eli, could you re-post your comments there? Andrew >>> I've split this patch in two and committed just the TM_FILE stuff. As >>> for the XM_FILE changes (and those 3 definitions), consider that tabled. > > > It seems to me that the whole discussion between Eli and yourself has > been beaten to death. We're basically stuck in a disagrement where both > point of views have their merit. > > I think it's time all global maintainers get involved in this discussion > and make a decision. Once the decision is taken, it needs to be > documented (gdb.texinfo for instance) so that people can refer to it. > > As a developper, I personally dislike to have to check the ARI everytime > I use anything in GDB for fear of using something deprecated. So marking > each instance as explicitly deprecated directly in the code is a good > move. Two questions were asked and need to be answered. I am adding my > proposed answers, as a starting point for your discussion: > > 1. When can some code be declared deprecated? > > IMO, some code should be declared deprecated when it has been > recognized that it should no longer be used in new changes. > It means that some code can be identified as deprecated before > a replacement has been implemented. > > There is a judgement call to make, obviously, as we don't want to > deprecate a central piece of GDB that makes it impossible for > somebody to submit a new port for instance without doing man-years > of work required to implement an alternate to the deprecated > feature. > > 2. How to identify deprecated code? > > Deprecated code should be explicitly marked as such directly > in the code, to avoid any accidental future usage, by prepending > "depreated_" to the entity names. > > Deprecated code can only be removed when no longer used. There can > be no time limit imposed between the time some code is deprecated, > and the time when it is removed. > > (the alternate solution suggested by Eli is the ARI) > > You should decide how the discussion will be held (privately or on > gdb-patches?), and whether it should include the steering committee > or not. > > Happy discussion. > > -- Joel