stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: process for filing issues
Date Wed, 09 Apr 2008 16:32:33 GMT
I put this up on the Wiki:
   http://wiki.apache.org/stdcxx/FilingIssues

There are few kinks that I'd like us to iron out, including which
version to assign a new issue to when it's not known to exist in
the most recent release (e.g., for 4.2.1, should it be trunk,
4.2.x., or 4.2.1?), and under what conditions should failures in
newly added tests should be considered a regression. Let's discuss.

Martin Sebor wrote:
> Here's the process I use for reference. Let me know if you have
> suggestions for improvements, otherwise I'd like to put it up
> on the Wiki as the recommended process to follow.
> 
>  1. using the cross-build result pages currently at
>       http://people.apache.org/~sebor/stdcxx/results/builds/
>     scan result page for an uncharacterized error (build problem,
>     abnormal exit, unexpected difference in example output)
> 
>  2. check other versions of the same platforms for the same error
> 
>  3. check 4.2.0 results for the same error on the closest
>     available platform
>     http://people.apache.org/~sebor/stdcxx-4.2.0/results/builds/
> 
>  4. 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 4.2.0, check the Regression box,
>        set Affects Version/s to trunk, and schedule for 4.2.1
>     *  otherwise (not a regression), set Affects Version/s to
>        4.2.0
>     *  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
> 
> Martin


Mime
View raw message