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

[David Holmes]

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 ?? 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.

Cheers,
David

> Cheers,
>
> -Joe
>