From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25516 invoked by alias); 13 Sep 2004 21:30: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 25476 invoked from network); 13 Sep 2004 21:30:16 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 13 Sep 2004 21:30:16 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id C16B347D92; Mon, 13 Sep 2004 14:30:15 -0700 (PDT) Date: Mon, 13 Sep 2004 21:30:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: Eli Zaretskii , kettenis@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [patch] Deprecate XM_FILE and TM_FILE Message-ID: <20040913213015.GC5843@gnat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41460B78.90005@gnu.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00218.txt.bz2 > 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