JBS policy around backing out of bug fixes : was(Re: [8u40] Request for Approval: 8067039: Revert changes to annotation attribute generation)

[joe darcy]

Catching up on email,

On 12/14/2014 9:50 PM, David Holmes wrote:
> On 15/12/2014 2:42 PM, joe darcy wrote:
>> Hello,
>>
>> On 12/14/2014 4:18 PM, David Holmes wrote:
>>> On 15/12/2014 1:33 AM, Seán Coffey wrote:
>>>>
>>>> On 13/12/2014 00:41, David Holmes wrote:
>>>>> Sean,
>>>>>
>>>>> This issue was discussed at some length when JBS was being set up.
>>>> David,
>>>>
>>>> I realise there was alot of discussion around JBS process when it was
>>>> being set up. IIRC, the custom verification field was a request from
>>>> Quality team to track bug fixes. For that reason, I imagine it's of 
>>>> most
>>>> interest to quality team. I normally focus on Status/Resolution 
>>>> fields.
>>>> Could I make a proposal that we mark anit-deltas with Resolution = Fix
>>>> Failed ? Is there any reason we can't ?
>>>
>>> You mean the bug for which the anti-delta was needed should be marked
>>> Resolution=fix-failed? I don't have a problem with that, but these
>>> aren't my rules.
>>>
>>>  It helps to keep JIRA queries
>>>> more simple and avoids having to look up a 3rd field in order to 
>>>> capture
>>>> the true state of a bug fix.
>>>>
>>>> Here's another example of a bug fix one would think was fixed in 
>>>> JDK 8 :
>>>> https://bugs.openjdk.java.net/browse/JDK-8025198
>>>
>>> It is fixed in the JDK-8. The "anti-delta" was only a partial
>>> anti-delta for the files that had been modified unintentionally. The
>>> actual fix is still present.
>>>
>>
>> I've checked my JBS notes. "Fix failed" wasn't one of the resolution
>> values available when JBS went live and I'm not sure when it was added.
>
> I thought I didn't recall this being an option from previous discussion.
>
>> In any case, for the JDK project, I don't think that resolution value
>> should be used; the JBS overview
>>
>>      https://wiki.openjdk.java.net/display/general/JBS+Overview
>>
>> documents the field values I mentioned earlier (status =
>> resolved/closed, resolution = fixed, verification = fix failed).
>>
>> A truly failed fix is an exceptional event and I don't really think it
>> is worthwhile to devote a resolution value to that case.
>
> ??? If the value already exists then why shouldn't we use it to 
> reflect a situation that it describes very well ?? 

I have a different first reaction: we should not be allowing changes to 
the JBS state model without explicit discussion and consideration.

> Backing out fixes with unintended consequences is something that the 
> hotspot processes are advocating more strongly now - so this might not 
> be as rare as it has been.
>

At the time of transitioning to JBS, "Fix failed" was vanishingly rare 
-- from memory perhaps a dozen instances out of 100,000+ bugs. (This 
rarity was moreso a reflection of processes that did not use the value 
rather than the absence of fixes which failed ;-) The use of "fix 
failed" may become more common with procedural changes.

My general thinking is that a resolution of fixed mean "a changeset was 
pushed for this bug into a release." Coupled with the policy of not 
re-using bug ids for multiple fixes, "a changeset was pushed for this 
bug" remains true whether or not it was a good changeset or a bad one 
and whether or not it had to be modified after being pushed, the largest 
modification being fully backed out. I would guess a "failed fix" is 
more often an incomplete or somewhat buggy fix rather than a fix that 
needs to be anti-delta'ed.

My sense fix "give me a list of changes in a release" is closer what 
people want when doing a query for

     fixVerion = $RELEASE and resolution = fixed

than "give me a list of changes in a release that did not need 
subsequent revision."

Therefore, I don't think "fix failed" (yet) rises to the level of a 
condition that needs its own resolution value and those interested in 
identifying such bugs should uses a query with another term.

HTH,

-Joe