This page describes the recommended process for filing issues found in nightly build results
- Using the cross-build result pages, scan the result page for an uncharacterized error (build problem, abnormal exit, unexpected difference in example output).
- Check other versions of the same platforms for components (locales, examples, tetsts, etc.) exhibiting the same error.
- Check the results for the most recent release for the same error on the closest available platform. For example, for stdcxx 4.2.0, use this page.
- File an issue for the problem:
if the problem is platform-specific, mention the platform in the Summary (e.g., [Sun C++ 5.8/Solaris/SPARC])
- if it's a regression from the previous release, check the Regression box, set Affects Version/s to trunk, and schedule it for the upcoming release.
- otherwise, if it's not a regression, set Affects Version/s to the most recent release (or all those known to exhibit the problem)
- include as much detail in Description as possible (use the {noformat} tag to disable Jira formatting of command lines, code snippets, and program output)
- set the Severity field as appropriate
- try to asses the Priority of the problem based on the platform (Primary, Secondary, Best Effort), the Severity of the problem (signal is usually worse than compilation error), and the area of the library it affects (an error in a test due to a compiler bug is of lower priority than a runtime error pointing to
std::string) - if possible, take a guess at the effort required in fixing the problem by setting the Original Estimate