CR 6860309 - solaris timing issue on thread startup
david.holmes at oracle.com
Wed Nov 16 01:44:16 UTC 2011
Still seems to me, based on the FAQ,
that the intent is for @bug to refer to the bug that the test is testing.
But as it is looking like this has been used in an ad-hoc manner anyway
I'll shut up now. ;-)
On 16/11/2011 10:47 AM, Iris Clark wrote:
> The current practice may be different, but...
> The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords:
> In the case of bugs against regression tests I've seen two approaches:
> 1. Addition of the bugid to the @bug tag
> 2. Addition of the "noreg-self" keyword to bugtraq
> Both technically fulfill the original intent. At one point there were audits to enforce this.
> Knowing how the audits worked (I personally preformed them for a while), I tended to favor adding the bugid to @bug as that would minimize the number of BugTraq queries. Even when the network and BugTraq were functioning perfectly, a BugTraq query always took longer than just looking at the source (which we were already looking at).
> Again, the above may no longer be the current practice or recommendation.
> -----Original Message-----
> From: Alan Bateman
> Sent: Tuesday, November 15, 2011 2:37 PM
> To: David Holmes
> Cc: Gary Adams; core-libs-dev at openjdk.java.net
> Subject: Re: CR 6860309 - solaris timing issue on thread startup
> On 15/11/2011 21:29, David Holmes wrote:
>> That was somewhat non-committal :) To me @bug says "these are the bugs
>> that this test is checking the fix for" hence not applicable in any of
>> the recent timing/race test fixes.
> It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now.
More information about the core-libs-dev