Oliver Braun wrote:
Hi *,
the OOo release status meeting from 2007/05/15 has accepted a proposal
for a new
nomination policy affecting child workspaces with a red tinderbox status
reported in EIS:
Child workspaces with a red tinderbox status need a valid justification
when
promoted to "ready for QA" state, otherwise the CWS will be rejected
from QA.
The justification is expected to be given from one of the developers
involved (usually the CWS owner) and should explain why it is o.k. to
nominate or integrate the particular child workspace in the current
state nonetheless.
Some guidance on what needs to be done when one of your CWS'es is
affected (including a list of known false positives) can be found at
http://wiki.services.openoffice.org/wiki/RedTinderboxStatusInEIS.
More info on Tinderbox/EIS integration can be found on
http://wiki.services.openoffice.org/wiki/TinderboxAndEISStatus.
Regards,
Oliver
This appears to not work well:
There appear to be known-broken lists so that some builds with errors
are nonetheless green (e.g., the 07/03 18:04 UTC edgy-jdk build with 474
errors at <http://go-oo.org/tinderbox/native93/status.html>). However,
if I have to check why a build is red, I can hardly tell which of the
assumed errors are true errors and which would be filtered out by the
known-broken list. (For example, looking at
<http://go-oo.org/tinderbox/gunzip.cgi?tree=native93&brief-log=1183511890.31720>,
which of the error message links should I concentrate on to argue with
QA that the CWS is fine despite the red tinderbox result for Mac-x86?)
In short: Where are the known-broken lists, and why can not the
tinderbox log pages like
<http://go-oo.org/tinderbox/gunzip.cgi?tree=native93&brief-log=1183511890.31720>
categorize the error message links as known-broken and not known-broken?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
