From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27117 invoked by alias); 24 Nov 2003 20:54:34 -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 27083 invoked from network); 24 Nov 2003 20:54:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 24 Nov 2003 20:54:32 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AONj6-0004ol-DP for ; Mon, 24 Nov 2003 15:54:32 -0500 Date: Mon, 24 Nov 2003 20:54:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses Message-ID: <20031124205432.GA18415@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3FC119EB.1060102@gnu.org> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <3FC25DCF.7060508@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC25DCF.7060508@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00543.txt.bz2 On Mon, Nov 24, 2003 at 02:36:47PM -0500, Andrew Cagney wrote: > > >Thank you for the details, Andrew, but you haven't answered Eli's > >question. The answer to his question lies in the leap between "blindly > >transform" and "Consequently" - why not just _leave_ them? > >DEPRECATED_STREQ is not an improvement over STREQ except for making > >things uglier. We've even got the ARI to remind us; what you've > >accomplished is shrinking the STREQ/STREQN column to zero at the > >expense of raising the deprecated column even higher. If that was all > >you wanted you could have done it in the ARI scripts. > > David summarized the rationale nicely. Some additional data points are > useful though: > > - no one looks at the ARI > Looking at the last month of weekly web page summaries they range from: > 2734 /gdb/ > .... > 170 /gdb/current/ > ... > 32 /ml/bug-gdb/2000-12/msg00014.html > but contain not one mention of the ARI (even though I refer to it > regularly). At least one now :) There are a number of other solutions to this. Have you considered making the ARI mail contributors for certain (low-false-positive) categories? Like, for instance, this one. The gcc-regression mailing list has several scripts to pull the ChangeLog entries since the last run and mail victims. It's extremely effective. > - no one should need to look at the ARI > GDB's code base should internally document the status of each interface. > That way, when someone goes to hack on something its status is very > clear. Contributors can look at a slab of code and know immediatly that > there is a problem. Maintainers can review a patch and know where a > deprecated interface is being used. > > - it's more transparent > It's clearly far harder for me (and you) to let slip through patches > that contain deprecated references. This is where we disagree, I think. Not that I'm arguing with either of the above. But I believe that the problems (below) need to be considered also. With work to make the ARI more used (as opposed to useful) I think you could save everyone a lot of time. > >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? > > This isn't exactly new: > > ChangeLog-1998: (struct frame_saved_regs): Deprecate. > ChangeLog-1998: (EXTRA_FRAME_INFO): Deprecate. > ChangeLog-1998: (get_frame_saved_regs): Deprecate. Copy the saved regs > into the > ChangeLog-1998: * symfile.c (allocate_symtab): Deprecate use of > ChangeLog-1999: memory-write-packet-size''. Deprecate ``set > remotepacketsize''. > ChangeLog-1999: print_transfer_performance. Deprecate. > ChangeLog-1999: deprecated gdb_file_init_astream(). > ChangeLog-1999: * serial.h (DEPRECATED_SERIAL_FD): Define. > ChangeLog-1999: * serial.c (deprecated_serial_fd): New function. > ChangeLog-1999: * ui-out.c (struct ui_out): Remove deprecated fields. > > With STREQ discussed: > > ChangeLog-2000: * TODO: Mention ``extern'' and ``STREQ'' cleanups. > ChangeLog-2000: * defs.h (STREQ, STRCMP, STREQN): Document that these > macros are > http://sources.redhat.com/ml/gdb-patches/2000-q1/msg00667.html > ('m sure there's a second thread but can't find it). Sure it isn't new. Other people grumbling at you when you deprecate things doesn't appear to be new either. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer