From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7925 invoked by alias); 24 Nov 2003 18:02:29 -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 7918 invoked from network); 24 Nov 2003 18:02:28 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 24 Nov 2003 18:02:28 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 7EF53C6B8; Mon, 24 Nov 2003 10:02:27 -0800 (PST) To: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC119EB.1060102@gnu.org> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> From: David Carlton Date: Mon, 24 Nov 2003 18:02:00 -0000 In-Reply-To: <20031124165047.GA2227@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 24 Nov 2003 11:50:48 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00528.txt.bz2 On Mon, 24 Nov 2003 11:50:48 -0500, Daniel Jacobowitz said: > You've been pushing very hard to renaming things to deprecated_foo > for a while now. I think I'm not the only other maintainer who > doesn't understand or approve. It's a lot of work for you; it > generates large patches and source churn; it causes patch rejects > and merge errors for other developers; and the rest of us don't see > or agree on the benefit. Isn't that the sort of thing which should > be discussed instead of implemented? Yes. Having said that, I think that deprecation is often a good idea. I like it when these conditions hold: 1) There is a new mechanism A replacing an old mechanism B. Everything that had been done with B can be done with A, and there is general agreement that A is better. 2) Adding 'deprecated_' will cause uses of B to diminish faster than not adding it would. Part 2 comes in to play if you don't plan to make the switch immediately (within the next month or so, say), and when you're afraid that people who haven't been closely following the relevant discussion will add uses of the old mechanism. I'm not sure that STREQ meets the second criterion - frequent contributors are good about not adding new uses of it. So, from that point of view, the merge difficulties (and even the newly introduced long lines) argue against it. I could go either way, though. David Carlton carlton@kealia.com