Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

[Iris Clark]

Hi, Bernard.

> > A bug is moved to Evaluated by a person who is qualified to make a 
> > judgment on the technical aspects of a solution.  The defined 
> > substatuses can be used to refine the level of understanding of the problem.
> 
> We should consider other pieces of information to capture the evaluated state
> without having to create an entirely new state (targeted release info,
> assigned engineer, comments, etc).  An evaluated state is also a fairly
> subjective state.  Until a fix has been created, you can't really be sure that
> you have fully understood and evaluated the issue. From a management
> standpoint, i most likely will want look at the bug comments and targeted
> release info than just rely on this state anyway.

Fewer statuses does not always mean less complexity.  While it may be possible
to derive this status based on the value of an existing field (or
combination), that isn't necessarily helpful for those who don't regularly use
the System.  As many have argued, the Evaluated status allows developers to
organize their work by providing general information for queries and makes it
possible for new developers to identify "starter" bugs.  For the
non-developer, it provides a simple way to interpret progress.

There are some tasks where you don't have the luxury to read all the text
associated with a bug.  This is particularly true when managing large numbers
of them.  In those cases, it would be cleaner if we had a queryable status,
rather than deducing that status from some number of fields which may or may
not be used by that OpenJDK Project.  The derivable solution creates a high
dependence on the fields that are used.  I don't think that we should require
synchronization on those fields for all OpenJDK Projects.  Furthermore, If we
get the derivable solution incorrect, it becomes hard for us to change and
track historically.

Thanks,
iris