Hi. 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: http://openjdk.java.net/guide/changePlanning.html#bug 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. Thanks, iris -----Original Message----- From: Alan Bateman Sent: Tuesday, November 15, 2011 2:37 PM To: David Holmes Cc: Gary Adams; core-libs-dev@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. -Alan.
