OpenJDK bug database: DRAFT Developer Workflow

[David Holmes]

Hi Iris,

On 15/12/2011 6:01 AM, Iris Clark wrote:
> 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 think we need the two statuses: "cause known" and "fix 
understood" ...

> 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).

That is often the case for simple bugs, but certainly not always.

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

I agree that the current Defer is not well applied or understood. In 
effect if you assign a bug to an indeterminate release it is effectively 
deferred. So whether a bug is "accepted" or "understood" it could still 
be deferred in the sense that it is not targeted for a specific future 
release.

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

Not sure why staying there indefinitely is an issue, other than 
cluttering reports.

> - 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".

This begs the question as to the long term management of JEPs. What 
happens to JEPs that are rejected, do they linger in a JEP repository?

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

I'm not aware of any way to run queries against mercurial the way we can 
with BQ and will be able to with Jira. I echo Joe's sentiment that 
having both resolved and unresolved issues be "closed" makes it harder 
to find those resolved issues. Doing bug triage is aided immensely if 
you can query which bugs were fixed in a specific build of a specific 
release.


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

I actually meant this as additional text for the document, to explain 
the circumstances when "will not fix" might be appropriate.

Cheers,
David

>
> Thanks again!
>
> iris