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

David

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