OpenJDK bug database: DRAFT Developer Workflow

[Iris Clark]

Hi, David.

First, thanks for taking the time to read the document and provide comments.
You've hit on some of the more difficult areas that I was hoping would come
up.

> The description for state "Understood" in the transition from dispatched was
> not at all what I would expect:
> 
> "This bug is either something which will be fixed as part of other work
> currently being conducted (but not quite a duplicate) or this bug was
> created specifically to describe planned changes."
> 
> ??? Later descriptions of "understood" seem more in line with today's
> meaning. 

Oops.  I thought I'd fixed all of those.  The text you quote should be
replaced with something that's closer to other descriptions of "understood".
I'll align this to match the others in the next draft.

> Though where it says;
> 
> "Sufficient investigation has been preformed to gain a basic understanding
> of how this bug/feature request should be addressed. There is no requirement
> that an actual solution be known at this time."
> 
> this matches more with "Cause known" than "Fix Understood".

The definition I provided does not adequately describe what one should expect
for this status; hence my question immediately after that line:

"The definition of this status should match the current
definition/expectation for "Fix Understood".  What is that definition?

Is it sufficient to remove the final sentence?  Perhaps it should be replaced
with a recommended confidence level?

"Sufficient investigation has been preformed to gain a basic understanding
of how this bug/feature request should be addressed and the associated risks."

> 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?  

> 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? 

Ok.  First let's clarify that the existing BT "Defer" status does NOT
correspond to the "deferral process" that's implemented by release management
during late stages of the release cycle.  (I expect those "deferrals" to be
covered by a separate "Approval Workflow".)

At least for JDK releases, the existing BT "Defer" status is very rarely
used.  I speculate that's because historically we've been strongly advised
against use.  Over time, it appears that use has crept in.  Don't quote me on
the numbers but I think we're talking about <400 bugs out of >200,000.  Some
of those bugs have been in "Defer" for years.  This is a fantastic way for
bugs to drop off our radar indefinitely as there is no expectation that there
be periodic review of anything that lands there.

Of the existing 6 substatus ("Future Project", "Code Freeze", "No Plan to
Fix", "No Resources Available", "Too Risky to Fix", "None"), "Future Project"
appears to be used the most.  It is often associated with bugs which some
people would have closed because at the time of the bug's submission the work
was entirely out of scope.  However, in some cases the IE left it open with
the expectation that the idea is valid and was within the realm of
possibility.  

I moved these bugs to "Closed: Future Project", because in those cases, it
seemed to be a more honest evaluation of the likelihood of the work getting
done and our current lack of review for those bugs.  It also allows us the
possibility of quickly finding that kind of long-term, innovative ideas.

So, getting back to the issue at hand.  What should we do with what I've
currently defined as "Closed: Future Project"?  There are at least 3 
possibilities:

- New "Accepted: Future Project" as you suggest.  We would need to define a
  lifecycle for these bugs (periodic review, etc.) so that that don't stay
  there indefinitely.

- New "Closed: Future Project", as currently defined.

- Decide that the bug system is not the right place to store these kinds of
  innovative ideas (perhaps JEP is).  Future submissions of this type moved to
  "Closed: Will Not Fix" and evaluation recommends that a JEP be filed.  Move
  all existing "Defer: Future Project" bugs to "Closed: Will not Fix".

- Other?

> I'd even
> like to see two different "closed" states to represent the two cases:
> a change was made, and a change was not made - that makes it easier to
> actually search for CRs that have been fixed in particular categories.

The source for the information you really want about whether a fix has been
applied should come from the source control system, not the bug system.
That's the only information you can really trust.  

> Not sure about the "not accepted" status. Seems applicable to RFEs
> more than bugs (a bug is either a bug or not). Even for RFE's it's not
> clear the IE is in a position to make that judgment call. Further,
> RFE's of a non-minor nature will come through as JEPs.

Agreed.  Perhaps we should just remove it entirely?  Objections?

> For "will not fix" we might clarify the reasoning eg: too risky for a
> given release (ie not backporting from 8 to 7); causes unacceptable
> incompatibilities; etc.

I suspect that there are too many possibilities.  Could this reasoning be
provided as part of the evaluation?

Thanks again!

iris