Target-specific bugs (was Re: Number of 3.3 hi-pri PRs going up)
Nathanael Nerode
neroden@twcny.rr.com
Sat Feb 22 09:01:00 GMT 2003
Joseph S. Myers wrote:
> On Sat, 22 Feb 2003, Nathanael Nerode wrote:
>
>
>>1. Platforms for which no 3.x build has been reported: Close all
>>target-specific bugs immediately and possibly deprecate the platform.
>
>
> We should close such bugs when support for the target is *removed* from
> mainline, not when the target is deprecated. (And this is something that
> does need to be done as part of the target removal process, just as stray
> references to the target and its problems need to be removed from
> trouble.texi and elsewhere in the manual and sources - preferably as part
> of the target removal rather than left for someone else to do later.)
>
> This may make sense for native platforms, but in general people do not
> seem to report their cross builds at all or submit testresults for them.
How sad...
> I would like to see a list of all supported platforms (which I think ought
> to go in install.texi, host/target specific notes, even where there are no
> specific notes for a system, just so that users can see exactly which
> systems are supported and what their target triples are) together with the
This would be a very, very good idea.
> list of those native systems which haven't had a 3.x build report or
> testresults sent and so are candidates for deprecation. (Also indicate
> which if any of those have had any user interest at all - questions asked
> about them, or bug reports saying they don't work.)
>
> Also remember that some target-specific bugs are in fact bugs in generic
> code that just happen only to show up on certain platforms.
Yeah. I'm trying to make suggestions which will help clear the bug
reports down to a managable quantity, though. Bugs which can't be
reproduced on maintained systems have no value in the bug tracking
system, unfortunately.
For another thought, I strongly suggest that any bug in feedback and
without feedback for 3 months be closed, and that this be documented
somewhere. (The standard I've been using is 6 months, which I think is
overly generous.)
More information about the Gcc
mailing list