OpenJDK bug database: DRAFT Developer Workflow

[Brian Beck]

On 1/3/12 5:14 PM, David Holmes wrote:
> On 4/01/2012 10:11 AM, Peter Jensen wrote:
>
[snip, snip]
> I don't see how asking a question relates/compares in any way to 
> having clearly defined states like "cause known" or "fix understood". 
> And of course you never know ALL of the implications - "fix 
> understood" doesn't imply absolute knowledge of every nuance, just as 
> actually fixing the bug doesn't imply you know ALL the implications of 
> the fix you've committed.
>
>> Management would be much better served by updated estimates and risk
>> evaluation. I've yet to meet a manager who, deadline looming or not,
>> would make a decision to commit-to-fix or reject a bug based on these
>> states.
>
> The states convey initial information used to discuss estimates and 
> risks pertaining to the bug. If every bug is just "accepted" then the 
> discussion has to start with "where are with this bug? do we know 
> what's causing it? do we have a fix?" instead of "I see the fix is 
> understood, what do we need to do before pushing it? Is it a high or 
> low-risk fix?"
>
> Just my opinions - YMMV
>
> David
> -----
After countless hours (maybe years!) of conducting bug review meetings, 
my experience is that *every* bug has a story.  Nobody is content to 
describe their work as "fix understood" or "cause known".  And without 
the story, reviewers can't make useful decisions about risks, rewards, 
estimates etc.  The story is (or should be) captured in the commentary 
and it must be read.  I can't think of any useful decisions that an 
RTeam or Eng. Mgr. could make simply by looking at a "cause known" or 
"fix understood" status.

Perhaps these statuses are useful for individual engineers to sort their 
bugs, but I don't see them helping any of the management functions.

Brian.