Re: [patch] Deprecate XM_FILE and TM_FILE

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Fri, 10 Sep 2004 12:29:50 +0300
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Thu, 9 Sep 2004 14:26:38 -0700
   > From: Joel Brobecker <brobecker@gnat.com>
   > Cc: Andrew Cagney <cagney@gnu.org>, 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