Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney <cagney@gnu.org>]

> Hi Eli,
> 
> 
>> If you are proposing a change in the current strategy, this issue
>> should be discussed (on gdb@, I guess).
> 
> 
> Okay.
> 
> 
>> For startesr, please define the ``long time'' after which it is okay, in
>> your opinion, to deprecate a platform.
> 
> 
> Three minor releases.

That would be ~18 months which is significantly longer than the current 
process.  But then again, the current process starts several (like 10) 
years later than I suspect is being suggested here.

> Supporting untested code costs resources because we can't upgrade the
> code to use new interfaces.  If we drop untested code, it will be easier
> to do work on the tested code.

By testing, you mean run through the testsuite?  Yes.

We're caught between a rock and a hard place.  Do a blind rewrite of the 
old code (which is effectively guarenteed to be wrong but will let us 
fool ourselves into thinking its "fixed"); retain backward compatibility 
until it gets updated (which is guarenteed to suffer bitrot but 
hopefully less likely to immediatly break - presumably at the time of 
the change both the old and new ways were tested); remove the relevant 
code.  At present, by doing a combination of the latter two, we're able 
to extract an extra year or so out of the unmaintained code with not too 
much effort.

> If we want to drop a platform, and a user wants to keep it supported,
> then they can volunteer to run the gdb test suite on it occasionally.

We already have the occasional but steady updates/fixes that are made to 
architectures by architecture maintainers (and others).

Andrew