Hi Iris,
Still seems to me, based on the FAQ,
http://openjdk.java.net/jtreg/faq.html
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. ;-)
Cheers,
David
On 16/11/2011 10:47 AM, Iris Clark wrote:
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.
