Re: [patch] Deprecate XM_FILE and TM_FILE

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Fri, 10 Sep 2004 14:41:30 +0200 (CEST)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: brobecker@gnat.com, cagney@gnu.org, gdb-patches@sources.redhat.com
> 
> 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.

This sounds like you say the same things that I say: deprecated stuff
gets removed without much discussion.

> 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?

When it is there in the sources, of course.

>    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?

We draw the line by deprecating things only when they are replaced by
the better mechanism.  This could be done by the same patch that
deprecates the old mechanism.

> 2) We need a way to stop people from using constructs that we are
>    phasing out.

We can easily do that (and actually do that) by rejecting patches that
use the old mechanism.

>    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?".

If that is the problem, we could have the list of features not to be
used spelled out somewhere.  This somewhere doesn't have to be in the
sources.

> 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.

I don't think ``sitting on lazy ass'' is a fair description of my
maintenance mode.

>    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.

We could have the ari script do that for us.  It could use a list of
old mechanisms mentioned above.

> 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.

I don't think the DJGPP port is lacking maintainership.  I suggested
to do the work to replace what is now done by XM_FILE.  The only thing
I ask for is not to deprecate XM_FILE before I'm done.  I really don't
understand what is all the fuss around such a simple and IMHO fair
request.