From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30682 invoked by alias); 10 Sep 2004 12:41:56 -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 30668 invoked from network); 10 Sep 2004 12:41:52 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 10 Sep 2004 12:41:52 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Fri, 10 Sep 2004 14:41:19 +0200 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id i8ACfUCu027343; Fri, 10 Sep 2004 14:41:30 +0200 (CEST) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id i8ACfUHq027340; Fri, 10 Sep 2004 14:41:30 +0200 (CEST) Date: Fri, 10 Sep 2004 12:41:00 -0000 Message-Id: <200409101241.i8ACfUHq027340@juw15.nfra.nl> From: Mark Kettenis To: eliz@gnu.org CC: brobecker@gnat.com, cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <01c49718$Blat.v2.2.2$de0204a0@zahav.net.il> (eliz@gnu.org) Subject: Re: [patch] Deprecate XM_FILE and TM_FILE 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> X-SW-Source: 2004-09/txt/msg00163.txt.bz2 Date: Fri, 10 Sep 2004 12:29:50 +0300 From: "Eli Zaretskii" > Date: Thu, 9 Sep 2004 14:26:38 -0700 > From: Joel Brobecker > Cc: Andrew Cagney , gdb-patches@sources.redhat.com > > > That might be so, but I've seen too many "Garbage collect FOO" > > messages lately to know that, following every release, many deprecated > > features get eliminated in patches treated as obvious, with no > > discussion. I cannot remember features being removed that were still actively used without discussion. What typically happens is that obsoleted stuff gets removed after the release. After that code gets eliminated there usually is quite a bit of stuff that's no longer used by any remaining code. In my book it's fairly obvious to remove that stuff, especially when it has been deprecated already. > Also, I don't think Andrew is using the "obvious" rule here. The patches > are nowhere near obvious, I agree. He's using the global maintainer > priviledge. I'm not against the priviledges nor about Andrew's right to use them. I'm against deprecating a feature that is being used by a maintained port before introducing alternative mechanisms that replace the feature being deprecated. I defenitely agree that we shouldn't just deprecate things when no alternative mechanism exists, but you must realize a few things: 1) When do you consider that an alternative mechanism exists? There is an alternative for XM_FILE. It's autoconf, and it has been around for quite some time now. It will take same work to get things autoconfiscated, and using alternative mechanisms for other deprecated things will require even more work. Where do we draw the line? 2) We need a way to stop people from using constructs that we are phasing out. Every now and then someone contributes a new port. People tend to copy code from existing ports. In doing so they also copy things that we want to get rid of. As a result it takes more time to review the associated changes. It might also discourage contributors if we tell them that they shouldn't use those features: "Why didn't you tell me that before?". 3) Deprecating things is an effective way of getting port maintainers from their lazy ass and actually do the work necessary to get rid of bad mechanisms. From time to time I tend to do a "grep -i deprecated" on the source files associated with the stuff I care about and fix things. The fact that prepending deprecated_ to things tends to make the code look so ugly helps in that respect. So we have to find the right balance here. I'm fairly happy with the current status quo as far as the stuff I'm (unofficially) maintaining is concerned: amd64, i386, m88k, sparc, sparc64, vax. I'm not too happy with what it's done to other targets like rs6000/powerpc, hppa and mips. But the real problem there is a lack of maintainership. Mark