Bug System Pilot Dev Workflow: DRAFT Accepted/Understood

Peter Jensen peter.jensen at oracle.com
Thu Jan 19 17:15:53 UTC 2012


On 01/18/12 22:31, Iris Clark wrote:
> 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.
It's no simpler than filtering a query result on a boolean field or tag 
value (it's not like you would not filter/sort on things like priority, 
category, etc. anyway).

It only indicates progress according to a sequential model that just 
doesn't fit all (most) issues, and only when an individual/team choose 
to actually use this state (there's no external pressure to use it 
consistently).
If you're not in a context where you can trust the usage (e.g. if you're 
doing general process monitoring and release management), you've  
complicate things because you then have to combine Open and Evaluate to 
get an accurate picture of how well Development processes bugs.

Finally, it also only indicates progress from the perspective of fixing 
the issue in a specific code base. It doesn't necessarily directly 
pertain to the problems of delivering a solution to the customer (may 
need to be delivered in multiple patches/releases), or learning 
everything we can/should from the incident (regression test, more 
testing of functional area, definition/observance of coding practices, ...)

>
> 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.
I don''t see how defining an optional value, the use of which is not 
"synchronized", for a general usage field, is any better.

I don't buy the arguments presented for the state Evaluated, but if you 
can demonstrate distinct process roles for Open and Evaluated, then I 
would be happy with it. I can also accept an argument of the form "we're 
used to do it this way, it works okay, so why change" :-)

>
> Thanks,
> iris




More information about the discuss mailing list