CR 6860309 - solaris timing issue on thread startup

Iris Clark iris.clark at
Wed Nov 16 00:47:50 UTC 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.


-----Original Message-----
From: Alan Bateman 
Sent: Tuesday, November 15, 2011 2:37 PM
To: David Holmes
Cc: Gary Adams; core-libs-dev at
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 mailing list