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