RFR(XS): 8075658: Mark intermittently failuring core-svc tests
joe darcy
joe.darcy at oracle.com
Fri Jul 17 16:46:25 UTC 2015
Hello,
Yes, my general guidance is to make sure flaky tests are marked as
"intermittent" in the test itself. This lets someone running the test
easily check if the test is known to be unreliable *in that state of the
sources*.
There is a upfront overhead to collecting information about the current
unreliable tests from the bug database, personal notes, etc. However, I
would expect the marginal cost to keep the intermittent-ness updated to
be small and marking the tests this way should allow easier analysis of
failures.
Thanks,
-Joe
On 7/17/2015 6:53 AM, olivier.lagneau at oracle.com wrote:
> Hi Katja,
>
> Looks ok to me too.
>
>>
>> It has been a relatively manual process and I'm not aware of a
>> mechanism how to sync test-key-bug. What I can do is to mark bugs I
>> went through with for example 'key-intermittent' label to distinguish
>> them form the new ones.
> That's another additional label, and as I understand Joe's comment
> most important is to mark them intermittent with jtreg flag.
> Don't have any other suggestions however.
>
> Olivier.
>
> On 17/07/2015 15:33, Yekaterina Kantserova wrote:
>> Jaroslav,
>>
>> Thank you for the review!
>>
>> It has been a relatively manual process and I'm not aware of a
>> mechanism how to sync test-key-bug. What I can do is to mark bugs I
>> went through with for example 'key-intermittent' label to distinguish
>> them form the new ones.
>>
>> Are there other suggestions?
>>
>> // Katja
>>
>>
>>
>> On 07/17/2015 03:04 PM, Jaroslav Bachorik wrote:
>>> Looks good.
>>>
>>> Is there any way to check that all the issues from the JBS query
>>> mentioned in JDK-8075658 are addressed?
>>>
>>> -JB-
>>>
>>> On 17.7.2015 14:47, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075658
>>>> webrev: http://cr.openjdk.java.net/~ykantser/8075658/webrev.00
>>>>
>>>> Thanks,
>>>> Katja
>>>
>>
>
More information about the serviceability-dev
mailing list