On 15 Mar 2007, at 12:45, Thorsten Ziehm wrote:
Hi Christian,
Jogi isn't kidding. Currently there isn't a rule for build-breaker on
tinderboxes. This has to be defined, which isn't done until now. We
got a new tooling in EIS and the QA does not know, what to do, when
a one platform is red.
Do you know, if the new tooling in EIS works without any error? Only
then it is possible to define a rule.
I saw many CWS in the last weeks and only some of them are green on
all platforms. But I couldn't found one, without an error.
So what should be the rules to reject a CWS, when 50 errors are shown,
but the color is green, or when 20 errors are shown and it is violet
or when 10 errors exists and it is red.
Only clear rules will help to eliminate these problems. But if a rule
is defined and exist, all CWS has to be handled like this.
Now that the issue has been raised, lets look at the process to see
if we can improve it.
Currently I do not know, what the numbers and colors should tell me.
A clear definition will help here.
+1
As far as I can tell, red means no build product produced, and green
means build product produced.
What the number of errors stands for I'm not sure. It could be that
this figure includes information from previous failed builds too.
Soon the information from the Buildbots (termite) will be available
too. I believe it would be benifical to have a date for the last
build to be included in the "Tinderbox Status" for each platform.
This will be extremely useful for when the buildbots are added.
Shaun
Regards,
Thorsten
Christian Lohmaier wrote:
On Thu, Mar 15, 2007 at 10:33:03AM +0100, Joerg Sievers wrote:
Christian Lohmaier wrote:
Good (or rather bad) example of wasted ressources:
The build breaks on Mac. This has been reported in EIS. But you
simply
ignored this and went one with the big testing.
And even now you still ignore the breaker without even finding it
necessary to mention it with any word.
that is not the truth: I have written a sentence there that I
have seen it
You're kidding, right? I wrote that message on Wed, 14 Mar 2007,
and now
look at the date of your comment: Was posted today. I postet the
note about the build-breaker on Jan 21, on Feb 10 and again
on Mar 9. And only now you acknowlege to have read it?
but I have no rule, no process which hinders - from QA point of
view - the nomination.
And you're kidding even more: You have no rule that tells you that
you
should reject anything that breaks the build? That cannot be true.
---------- Comment from jsi Do Mrz 15 09:15:20 +0100 2007 ----------
I have no idea if a red Tinderbox-entry will block something but
I have no rule that I have to look at it. From QA point of view
the CWS is okay for integration.
-------------------------------------------------------------------
If you want to say: QA itself should not be bothered to check
tinderbox
status themselves, then fine. But: I already checked the status
for you
and told you it breaks. [1]
_Release Engineering_ should have an interest to get the builds
done on all platforms otherwise they get more work to do.
[1] And even looking yourself whether it breaks or not is easy.
EIS has
the tinderboxstatus built-in now. Just look at the color of the
columns.
If somebody is color-blind and cannot distinguish the green from the
red, then just ask me to change the colors.
ciao
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
