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

[Seán Coffey]

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

regards,
Sean.

>
> David
>
> On 13/12/2014 1:40 AM, Seán Coffey wrote:
>> Joe,
>>
>> Thanks for the update. I was not aware of the below process. I have to
>> add that I find it counter-intuitive. Anyone looking at bug x which has
>> status "Fixed" would assume it's fixed! It's dangerous. Could we move
>> resolution to "Fix Failed" instead? - that field also exists. Alot of
>> JIRA queries would have to be rewritten if the below policy remains.
>> Release note generation queries, unresolved bug queries, etc. Backing
>> out bug fixes is rare enough thankfully but it's an important event to
>> capture.
>>
>> regards,
>> Sean.
>>
>> On 12/12/14 01:21, joe darcy wrote:
>>> Hello,
>>>
>>> With my JBS designed hat on, I think the resting state of the original
>>> bugs being reverted should be as follows:
>>>
>>> * status = closed
>>> * resolution = fixed
>>> * verification = fixed-failed
>>>
>>> This indicates a changeset was pushed for the bug (resolution =
>>> fixed), no more action is expected (status = closed), but that the fix
>>> was problematic (verification = fixed-failed).
>>>
>>> The bug should also have a link to the bug for the revision.
>>>
>>> HTH,
>>>
>>> -Joe
>>>
>>> On 12/11/2014 6:52 AM, Seán Coffey wrote:
>>>> Approved. Please add 9-na to the bug report.
>>>>
>>>> I've not sure what bug record policy is in such scenarios but I think
>>>> the
>>>> 8u40 records for JDK-8029012 and JDK-8065132 need to be reverted to
>>>> something like "will not fix" ?
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 11/12/2014 14:43, Eric McCorkle wrote:
>>>>> Please approve JDK-8067039, which reverts JDK-8029012 and 
>>>>> JDK-8065132,
>>>>> which cause previous versions of javac in 8 not to be able to load 
>>>>> some
>>>>> classfiles generated by the current 8u javac.
>>>>>
>>>>> After discussions amongst the langtools team, it was decided that the
>>>>> change should be backed out in 8u, but kept in 9 in order to work
>>>>> towards a more complete solution to the underlying problem (see
>>>>> JDK-8066725 and JDK-8062582 for details)
>>>>>
>>>>> The patch was created cleanly by reverting JDK-8029012 and 
>>>>> JDK-8065132.
>>>>>   The patch ran cleanly through a JPRT run.  Review was conducted on
>>>>> compiler-dev, and it was approved by Jonathan Gibbons.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~emc/8067039/
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067039
>>>>
>>>
>>