OpenJDK bug database: DRAFT Developer Workflow

[David Holmes]

Hi Iris,

A few initial comments.

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

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

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.

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.

That's all for now.

Cheers,
David Holmes

On 14/12/2011 5: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