CR 6860309 - solaris timing issue on thread startup
iris.clark at oracle.com
Tue Nov 15 16:47:50 PST 2011
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.
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