[commit] Deprecate remaining STREQ uses
Andrew Cagney
cagney@gnu.org
Sat Dec 13 19:40:00 GMT 2003
> 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
More information about the Gdb
mailing list