OpenJDK bug database: DRAFT Developer Workflow

[Joe Darcy]

On 12/16/2011 11:07 AM, Iris Clark wrote:
> Hi!
>
>>>> I really like what we currently have in terms of:
>>>> - cause known (problem has been identified)
>>>> - fix understood (a solution seems to have been devised)
>>>> - fix in progress (actively implementing the solution)
>>>>
>>>> As an IE (and someone who watches many new bug reports) I will often
>>>> take a bug to "cause known" as part of my initial eval. Combining an
>>>> understanding of the problem with the discovery of a solution into
>>>> one state loses very important information in my opinion. For
>>>> example, a bug with an understood fix can be easily picked up by a new
>>>> developer as a "starter" bug. I agree that when we remove statuses,
>>>> information may be lost.
>>> I had combined these two statuses because my impression was that they
>>> were not currently being used effectively.  What seems to happen in
>>> many cases is that once sufficient investigation has been done to
>>> identify the cause, the recommendation for a solution would be known as
>>> well).
>>>
>>> What experience do other people have with these statuses?
>> Looking over the 100+ open bugs where I'm the responsible engineer, I have
>> about 1/3 in accept state, 1/3 in cause known, and 1/3 in fix understood.
>>
>> Should these three related conditions about an increasing understanding of the
>> bug be covered in one state with three substates?
> It's a possibility.  I want to step back to think about what exactly we need
> to represent.  Let's start by think about what the various points of a bug's
> life are and the points are of interest (and to who).  Here's my basic
> understanding of what happens to a bug from the time it come in
> (i.e. currently "Dispatched") to the time somebody is actively working on it
> (i.e. "Fix in Progress").
>
> Assume adjustments to bug content as appropriate for every step.
>
> 1.  Dispatched:  A bug comes in.
> 2.  Accepted*:  Component teams do initial triage.  The goal is to verify that
>      there's sufficient information to investigate the bug and determine
>      importance of the reported problem assuming it is real.  An initial
>      Priority, Cat/Subcat, and target release are verified/assigned as
>      appropriate.
>      NOTE:  There is no guarantee that the problem actually exists!
> 3.  The reported problem reproduced.  Priority, target release, etc. may be
>      adjusted.
> 4.  BT Cause Known/JIRA Understood:  Sufficient investigation preformed to
>      gain a basic understanding of how the problem should be addressed.
>      Evaluation updated.
> 5.  BT Fix Understood/JIRA Understood:  A potential solution is devised.
>      Impact and risks associated with the solution are known.  Suggested fix
>      updated.
> 6.  Fix in Progress:  Active work started to address the problem.
>
> Did I miss anything?   [ Note that 3 does not have a name in either the
> proposed JIRA workflow or BT.  Minimally, that needs to be addressed. ]

I don't know is the reproduction or non-reproduction needs to be 
captured formally in the database model as opposed to in comments.

Is there interest in generating statistics like, what percentage of 
incoming bugs cannot be reproduced?

> 3-5 feel like they're very tightly related so are perhaps a single status with
> sequenced substatuses?  (I don't know if JIRA supports the concept of "sequenced
> substatuses", so these might need to be individual statuses.)
>
> [ We'll need to visit the names after we decide what they should represent. ]

I suggest categorize the main-line states with indented substates as

Dispatched
Investigating
     accepted
     cause known
     fix understood
Fix(ing) in progress
Fixed
Resolved
     Verified
     Unverified


>>>> I don't think "closed: future project" works very well. Once a bug is
>>>> closed it should remain closed in my view. Maybe a new substatus of
>>>> "accepted" could be "future project" to indicate deferral?
>> I believe the intention of "closed: future project" state is intended to more
>> neatly address issues like a "Java should have a module system" bug, filed
>> back in 1996.  Leaving these is a chronic accepted or cause known state for
>> years obscures other issues
> Does it feel like we have a lot of these kinds of bugs?  Would it make it
> easier to close these and similar bugs if "Closed: Future Project" exists?
>

Some areas do have a large percentage of such bugs, for example Java 
language features.

-Joe