Re: [patch] Deprecate XM_FILE and TM_FILE

[Andrew Cagney <cagney@gnu.org>]

>>> Date: Sun, 12 Sep 2004 14:04:47 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> Cc: Mark Kettenis <kettenis@gnu.org>, brobecker@gnat.com,
>>>         gdb-patches@sources.redhat.com
>>> 
>>> I think this debate is over the point at which something can be deprecated.
> 
> 
> It's about a point where something can be deprecated, and also about
> the conditions that should be fulfilled for that.

I think this is progress, this discussion is finally focusing in on 
specific concerns.

>>> For GDB, as soon as we've got the new mechanism up and running - 
>>> confirming its ok - we're going to draw a line and deprecate the old 
>>> mechanisms.  We're not going to require that every single detail of 
>>> every single dependant variant also be addressed.
> 
> 
> I don't know about ``we'', but as far as I'm concerned, I cannot
> approve a patch that deprecates XM_FILE as long as the 3 defines in
> xm-go32.h are not set by an alternative non-deprecated mechanism.
> 
> 
>>>> > We can easily do that (and actually do that) by rejecting patches that
>>>> > use the old mechanism.
>>
>>> 
>>> We don't.
> 
> 
> Yes, we do.  You can find examples of that in the archives, including
> messages by yourself.

In the past, yes.  Two problems were identifed:

- there was no way for a contributor to predict ahead of time if/when 
``old'' mechanisms would not be accepted - the process was comparable to 
a lottery :-(

- patch reviewers were not tracking / rejecting  code using ``old'' - I 
was the one running around asking people to not use old mechanisms (not 
a good move ;-)

As a consequence we now explicitly deprecate: require a clear explicit 
weeks notice before someing is deprecated; and requiring that 
contributions decrease the deprecation count; and requiring that patch 
reviewers check for this.

The ARI currently identifies rougly 70 ``old'' mechanisms as candidates 
for deprecation (possibly redundant, broken, unused, ...).  I don't 
require any patch reviewer to track them, and I don't require any 
contributor to implement the work needed to formally deprecate them.

>>> In the past, requests to not use old mechanisms have been [er]
>>> declined
> 
> 
> If such a request is declined, we can reject the patch.  I don't see a
> problem here.

That is deprecation.

For us to reject such a patch we must have clearly, explicitly and 
formally identify the mechanism as one that should not be used, and 
recorded the decision in a way that both the patch reviewer and 
contributor can quickly and efficiently access.

Andrew