RFR: Filing bug, ProblemListing, Backing out [v2]

[David Holmes]

On 7/07/2020 8:56 am, Igor Ignatyev wrote:
> Hi David,
> 
>> On Jul 6, 2020, at 3:41 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Hi Igor,
>>
>> On 7/07/2020 8:36 am, Igor Ignatyev wrote:
>>> On Mon, 6 Jul 2020 22:25:58 GMT, Jesper Wilhelmsson 
>>> <jwilhelm at openjdk.org <mailto:jwilhelm at openjdk.org>> wrote:
>>>>> src/next.md line 154:
>>>>>
>>>>>> 153: #. Close the original JBS issue **(O)**.
>>>>>> 154:    * "Verify" the issue and choose "Fix Failed".
>>>>>> 155: #. If the intention is to fix the change and submit it again, 
>>>>>> create a redo-issue **(R)** to track that the work
>>>>>> still needs to be done.
>>>>>
>>>>> I have strong objections to fix failed ever being used and oppose 
>>>>> it being recommended here. Unless the fixer and their
>>>>> reviewers completely failed at their job what you usually have is 
>>>>> some other problem caused by the fix and the fix
>>>>> actually succeeded.
>>>>
>>>> I guess this is a question for those who normally handle fix 
>>>> verification and may have scripts that look for different
>>>> verifications.
>>>> There's only four values to choose from: "None", "Verified", "Not 
>>>> verified", and "Fix failed".
>>>> "Verified" means that the fix solved the problem and no more action 
>>>> is required, so this is clearly not right. "Not
>>>> verified" seems wrong since it actually was verified that the fix 
>>>> caused problems - or it wouldn't need to be backed
>>>> out. "None" could be used in my mind, but I can imagine that there 
>>>> are filters that treats "None" as issues that needs
>>>> verification. So changing to using this would probably cause 
>>>> problems. That leaves "Fix failed".  Maybe Joe knows why
>>>> this was designed as it is?  Anyhow, it is the current process and 
>>>> we need to bring it up with the right people before
>>>> changing it.
>>> AFAIK, The verification process isn't part of any OpenJDK process and 
>>> is used/done mainly internally by Oracle. why do
>>> you think that verification status should be set for all backed out 
>>> issues?
>>
>> That was the process that was defined. If a fix has to be backed out 
>> then the fix is considered to have "failed".
> 
> ok, but this meaning is a bit different from the one in the verification 
> process, where
>   - 'Verified' means that someone checked that the defect described in 
> the issue has been addressed by the fix, and it actually was;
>   - 'Fix failed' means that someone checked that the defect described in 
> the issue has been addressed by the fix, but it actually was not, i.e. 
> the defect still exists after the fix.

I thought "fix failed" was more broadly defined as either not fixing the 
original issue, or introducing additional breakage.

In terms of backports I would expect anything marked as "fix failed" to 
not be backported, and then the backout issue would also not be 
backported. But sometimes it isn't that simple.

But these are just my recollections from the earlier definition of the 
backing out process. And as you note the Verification process is really 
an Oracle specific concept exposed in JBS. I'm not sure how to deal with 
that. There aren't really any guidelines on how to use JBS in the 
OpenJDK process docs.

Cheers,
David

> 
> Although, I personally don't see this difference as a big deal, yet I'd 
> imagine that there are some metrics/criteria based on verification 
> status, and inclusion of all backouts to the pile of 'Fix failed' might 
> have some implications, so I'd recommend checking w/ people who track 
> that sort of data (unless it has been already done when the backing out 
> process has been established)
> 
> (just for completeness), other verification statues:
>   - 'Not verified' means that a) for some reasons, it has been decided 
> not to verify the issue; or b) there were problems during verification, 
> so it was impossible/hard to verify the issue;
>   - 'None' is a default value, i.e. none has worked on the issue's 
> verification
> 
> -- Igor
> 
> 
>> David
>> -----
>>
>>> -------------
>>> PR:https://git.openjdk.java.net/guide/pull/21
>