Bugzilla and build bugs

["Joseph S. Myers" <joseph at codesourcery dot com>]

I mentioned this in bugs 11878 and 333, but it's probably better here for 
a wider audience:

We have the current practice of telling people not to submit build 
problems to Bugzilla and closing such reports as duplicates of bug 333.

I don't think this is a good practice; build bugs are bugs much like other 
bugs, which may be valid or user error and may or may not have sufficient 
information when first reported; they should be treated like other bugs.  
If there's insufficient information or the reporter needs to investigate 
further, the bug is just as good a place as libc-help for the discussions 
with the reporter to take place (while the bug is in WAITING state).

If a bug is reporting that things don't work in a configuration that is 
unsupported, we should at least try to make configure detect this problem 
as early as possible rather than just telling the user it's their problem.  
For example, for several years glibc hasn't supported building for plain 
i386; you need at least -march=i486 or you'll get errors about missing 
__sync_* at link time.  Rather than closing such reports as user error (at 
least two, 10060 and 10062, were marked duplicates and then reopened), we 
should interpret them as representing a bug in the configure scripts and 
make the scripts detect and report the problem

It probably makes sense to have a new component "build" for problems 
building glibc or reports that it's completely broken in a particular 
configuration.  For failures of particular testcases in the testsuite, I 
think existing components such as "libc" and "ports" are more appropriate.

Comments?

-- 
Joseph S. Myers
joseph@codesourcery.com