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