Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.146.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=g1EXXl+PoCkqtJyaIQu66tPU95w1vAyrrSRsHjyO5ypQvC+4vb/sAQUKNdWBgEqYolbK+15oB0XRaR0zzQ2U5C64tnVAfapaeYxKTgOemKnDWgMVb7y3m+IQlIcTchCSR5+OwZWt21IaysCg5ggdUtvF5nX996CvWey23YjtJc0=
Message-ID: <47FFDCA8.5010000@roguewave.com>
Date: Fri, 11 Apr 2008 15:48:24 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: process for filing issues
References: <47F66819.5020400@roguewave.com> <47FCEFA1.8030802@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A36EB@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A36EB@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Eric Lemings wrote:
>  
> I'd like to propose the following change to the process for filing
> issues.  
> 
> "After an issue is created and categorized as a defect (bug), it
> can not be assigned to a particular release until the scope of the
> issue is determined (i.e. the causality of the issue needs to be
> analyzed)."

I take it that by "scope" you mean the effort the problem will take
to resolve (and not, for example, the impact on users).

> 
> If this is not done, the scope of the issue can easily fall outside
> the plans for the release.  If -- for example -- we're planning to
> release a new version -- even a patch release -- in a matter of
> weeks or days, assigning 8 new unscoped issues to the release within
> a 2 day timeframe will only wreck those plans.

I think it's the task of the Release Manager to decide which issues
should be looked and might need to be addressed in the release they
manage and which ones can safely be deferred or ignored. In my view,
if we discover a serious regression late in the release cycle we'll
need to fix the regression regardless of the deadline and no matter
how long it might take. Avoiding such regressions is more important
(and usually less costly) than meeting a deadline but causing all
kinds of pain to users.

What's happening with 4.2.1, unfortunately, is that there are
a large number failures in the test suite that we don't have much
of an understanding of and that might be hiding serious problems
(e.g., STDCXX-843 precipitated by the seemingly innocuous
STDCXX-826).

Btw., from a more practical point of view, if all problems found in
nightly builds needed to be analyzed in enough detail to be able to
tell how much time each would take to fix before it could be worked
on we'd almost never even get started on them because the analysis
is usually the most time-consuming stage.

> 
> Would like to see a vote taken on this proposal.

To formally bring up a proposal for a vote start the subject with
[VOTE]. In this case, I don't think having a vote on a change to
an informal process that itself hasn't been voted on yet would
make sense.

Martin

> 
> Thanks,
> Brad.
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Wednesday, April 09, 2008 10:33 AM
>> To: dev@stdcxx.apache.org
>> Subject: Re: process for filing issues
>>
>> 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
>>