FW: OpenJDK bug database: DRAFT Developer Workflow

Iris Clark iris.clark at oracle.com
Fri Dec 16 22:45:04 UTC 2011


John said his message bounced.   Attempting to forward.

 

iris

 

From: John Pampuch 
Sent: Friday, December 16, 2011 2:20 PM
To: discuss at openjdk.java.net
Subject: Re: OpenJDK bug database: DRAFT Developer Workflow

 

Iris-

One concern I have in the "Accepted" state that you describe below is that it may set expectations with someone who is paying attention to the bug.  On many bugs, the target release can't really be determined until we understand the bug better.  If we could, I'd prefer requiring setting the target release until step 4.

-John

On 12/16/11 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. ]
 
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 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?
 
Thanks,
iris

--------------050600050202000504050809-- 



More information about the discuss mailing list