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

[David Holmes]

Sean,

This issue was discussed at some length when JBS was being set up.

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