From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32106 invoked by alias); 15 Sep 2004 12:50:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32097 invoked from network); 15 Sep 2004 12:50:20 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 15 Sep 2004 12:50:20 -0000 Received: from zaretski (pns03-206-187.inter.net.il [80.230.206.187]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CON06025 (AUTH halo1); Wed, 15 Sep 2004 15:50:14 +0300 (IDT) Date: Wed, 15 Sep 2004 12:50:00 -0000 From: "Eli Zaretskii" To: Joel Brobecker Message-ID: <01c49b22$Blat.v2.2.2$79aeaae0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <20040913213015.GC5843@gnat.com> (message from Joel Brobecker on Mon, 13 Sep 2004 14:30:15 -0700) Subject: Re: [patch] Deprecate XM_FILE and TM_FILE Reply-to: Eli Zaretskii 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> X-SW-Source: 2004-09/txt/msg00120.txt.bz2 [I've moved this to gdb@, as gdb-patches@ seems an improper place to discuss such issues.] > Date: Mon, 13 Sep 2004 14:30:15 -0700 > From: Joel Brobecker > Cc: Eli Zaretskii , kettenis@gnu.org, > gdb-patches@sources.redhat.com > > 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. "Identified as deprecated" and "declared deprecated" need not happen at the same time. That time might (and IMHO should) be used to implement the replacement. > 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. I note that you didn't suggest any way out of this contradiction. I did suggest such a way: implement and commit the alternate mechanism before or together with the patch that marks the old code deprecated. > 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. This doesn't ensure that accidental future use is avoided, because not all contributors have the latest CVS before their eyes when they work on their contribution. A requirement that everything important for the contributor to get his/her code right the first time be in the code is IMHO ridiculous: it will, for example, cause us to spill a large part of gdbint.texinfo into the sources, as well as the contents of MAINTAINERS and PROBLEMS. The correct (IMHO) way out of this predicament is to request that contributors read all the relevant pieces of code and documentation (if they don't know, they can ask where to look). Of course, this doesn't eliminate a possibility that they will overlook, but I'm not aware of any project that avoided that with a 100% insurance; I don't see why this should be such a great deal here. More generally, AFAIR the "depreated_" stunt was invented mainly as an aid to the maintainer(s): to make their job easier when they want to know what stuff is candidate for deletion. It is a bit funny to see this convenience trick sudenly being inflated with so much ideology. > You should decide how the discussion will be held (privately or on > gdb-patches?), and whether it should include the steering committee > or not. IMHO, the steering committee is just a slogan: they never contributed anything helpful in any important discussion we've had lately, or ever. So I think gdb@ is a good place to discuss this. In any case, one thing that I think should never happen is that a global maintainer posts a patch a which deprecates a feature used by a maintained port without first asking for an _explicit_ approval of that port's maintainer for such a move[1]. That is not only good management practice (that is AFAIK codified in our procedures), it is also what simple decency to one's colleagues suggests. If we fail to agree to that, then we are not a team, but simply a bunch of unrelated people, each one pursuing his/her own agenda. ------------------ [1] One exception is when the area/port maintainer is unresponsive to the degree that it is impractical to wait for his/her approval or disapproval.