OpenJDK bug database: DRAFT Developer Workflow

[Joe Darcy]

Hi Iris.

Thanks for sending this draft out.

To add to some of the discussions that have already occurred around 
possible workflows, rather than being a pure boolean value, the fixed 
state could have, say a set of URLs associated with it.  The URLs could 
be pointers to the Hg changesets comprising to the fix.

(The Sun legacy bug system had different states for "fixed 
available"/"fixed" and "fixed delivered"/"integrated."  A bug is 
considered fixed when it is pushed to a staging repository like TL and a 
bug is considered integrated when it hits the master repository.  So the 
old bug state model implicitly assumes two levels of managed 
repositories, which is not always a valid assumption.  For example, for 
OpenJDK 6, we only have a one-level master repository so the fixed state 
on an OpenJDK 6 bug was an invalid condition.  Since the fixed and 
integrated states differ only in *where* the fix is present, I think 
modeling that fact more directly in the set of states is preferable.)

If a fixed state with URLs is decided upon, it would be convenient if 
the Hg push hooks for the repositories automatically updated the bug 
with the changeset URL.

Some other comments on the state model.  There may be value in having a 
new "resolved" state with "verified" and "unverified" substates.  With 
those states, the usual sets of transitions would be

dispatched -> accepted -> understood -> fix in progress -> fixed -> resolved

The state model influences what is easy to query for.  As one of the 
many masters of a  bug system, as an engineer I'd like the following 
query to be very easy to issue: what is the set of issues that were 
successfully resolved in a release because of code changes on my part?  
Having multiple substates of "closed" corresponding to this situation 
complicates the query.

(Again commenting on the legacy JDK bug system, previously "integrated" 
was the expected terminal state of a successful bug fix.  However, more 
recently the quality team is supposed to verify whether or not fixes are 
present and valid  so the expected terminal state is now "closed - 
verified" or sometimes "closed - unverified", which is inconvenient to 
query for in some of the main tools used to work with the bug system.)

If the fix failed state is going to be kept, having it as a substate of 
closed is better than preserving it as its own state.  Given the jcheck 
rules against reusing bug ids, if a fix has failed, a new bug has to be 
filed to resolve the problem.

Cheers,

-Joe


On 12/13/2011 11:39 AM, Iris Clark wrote:
> Hi!
>
> I'm defining requirements for the OpenJDK bug database [1].  As one
> would guess, it's not easy.  We have more than 15 years of data,
> process evolution, and supporting tools that we need to consider.
> Opinions on the effectiveness of existing process and tools vary.
> Many people with different roles (end-users, developers, quality,
> release management, etc.) need to be able to access the system.
>
> I've written a preliminary draft of what the pilot workflow for bugs
> and RFEs might look like.  It is based on the existing bug system with
> modifications to omit portions that aren't used.  There is no
> requirement that we stick closely to this draft, though any changes
> will need to consider the impact on data migration.  It still needs
> quite a bit of work.
>
>    http://cr.openjdk.java.net/~iris/jira/JIRAforOpenJDK.html
>
> Please send feedback/comments to this mailing list.  I'll provide
> regular updates as feedback is incorporated and I fill in other
> sections of the document.
>
> Thanks,
> iris
>
> [1] http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html