| Summary: | Too many Testsuite FAILs = email > 400K = bounce | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Rob <rob1weld> |
| Component: | web | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | major | CC: | gcc-bugs, manu |
| Priority: | P3 | ||
| Version: | 4.4.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
|
Description
Rob
2009-02-07 11:17:52 UTC
Subject: Re: New: trunk revision 143992 - Too many Testsuite FAILs = email > 400K = bounce On Sat, 7 Feb 2009, rob1weld at aol dot com wrote: > This causes a bounce reply message which _might_ mean that > tests with the most failures (and require fixing quicker) > will not be included in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/ The purpose of the gcc-testresults list is not for humans to read and identify bugs to fix; it is so that if you have a failure you can do a search and see what subset of platforms it appears on and when it appeared on those platforms, and maybe learn more about the underlying cause that way. If a target is *completely or substantially broken*, a failure of a test there is unlikely to be related to a failure of that test on a target that is not completely or substantially broken, so results for such targets add little value, and the filter serves a useful purpose in avoiding cluttering gcc-testresults with completely broken results and wasting bandwidth and disk space for copies of completely broken results. If your tests show such substantial breakage that the results bounce, you should fix the problems shown until the results are clean enough, or file a clear and specific bug report about the issues shown *only if you can make sure it really is the target support that is broken, not the test environment on your specific system*. (Such breakage can easily be a problem with your system, not with GCC. For example, if you have a broken version of expect that truncates output, as discussed in bug 12096.) I tried to lower the "Priority" but I can not alter my own Bug Reports. (In reply to comment #1) > Subject: Re: New: trunk revision 143992 - Too many Testsuite > FAILs = email > 400K = bounce > On Sat, 7 Feb 2009, rob1weld at aol dot com wrote: > > This causes a bounce reply message which _might_ mean that > > tests with the most failures (and require fixing quicker) > > will not be included in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/ > > The purpose of the gcc-testresults list is not for humans to read and > identify bugs to fix; it is so that if you have a failure you can do a > ... ... > If a target is *completely or substantially broken*, a failure of a test > there is unlikely to be related to a failure of that test on a target that > is not completely or substantially broken, so results for such targets add > little value, and the filter serves a useful purpose in avoiding > cluttering gcc-testresults with completely broken results and wasting > bandwidth and disk space for copies of completely broken results. > > If your tests show such substantial breakage that the results bounce, you > should fix the problems shown until the results are clean enough, or file Hi Joseph, I have investigated the reason behind the extra messages and combined with your comments (even though you are !@gnu.org) I an going to reduce the "Severity". If someone who runs this website (and/or those scripts) desires to increase the mail limit by 50k then they can; and if they do not desire to do so then that is OK (if they want reports to bounce when over the limit they set). Thanks, Rob ---- On an unrelated note: You can fix these messages by either "doing the wrong thing" and rolling back recent changes in the Trunk which exposed this Bug (in ld) or you can upgrade your Operating System to OpenSolaris 2009.06 (that may be tough for some people to do). So time for you to upgrade ... Closed as WONTFIX per Joseph comments. Thanks for the report nonetheless. |