OpenJDK bug database: DRAFT Developer Workflow

John Pampuch john.pampuch at oracle.com
Tue Dec 20 00:23:15 UTC 2011


So the implication is that the 'targeted' release is a target of 
analysis, but not necessarily for a fix.  I'll bet that isn't the first 
thought people have when they see that a bug is targeted to a release.

I also noticed we've collapsed "Cause Known" and "Fix Understood" into a 
single state of "Understood".  For many bugs, this makes sense, but I'm 
sure most engineers have also worked on bugs where there is a 
considerable difference between knowing the cause and knowing the 
solution.  Is there an advantage to removing this additionalstate?  
Could we have sub-statuses to "Understood" that engineers who choose to 
use them could?

-John

On 12/19/11 9:30 AM, Brian Beck wrote:
> On 12/17/11 11:25 PM, Georges Saab wrote:
>
> [snip]
>> 2. IMHO targeting should not be viewed as a commitment TO FIX in a 
>> specific release, rather a commitment TO WORK on
>> the bug in the context of the release.  For instance, a bug which 
>> appears to be very important if it really exists might be
>> immediately targeted to the current update release, meaning -- we 
>> need to work on this in the context of this release
>> until we know that it is not a bug or not as important a bug as it 
>> sounds now, in which case it could be retargeted to a
>> later release.
> Furthermore, IMAHO, targeting should not be considered a *commitment* 
> at all.  Targeting is an intention. Re-targeting should not be seen as 
> breaking a commitment but, rather, a normal action given new 
> information about a bug or the world it lives in.
>
> Brian.



More information about the discuss mailing list