Hi Christian,
Christian Lohmaier wrote:
IMHO, none of these options are suitable for practical life.
Indeed.
I disagree. Why is asking for help not a practical solution?
Why would integrating breaking stuff and then have the herd deal with it
be any better? (You'll then have a breaking master, and the cws that get
created on that cws will of course break as well, until somebody files a
patch and the tinderbox admins add it to their pool)
It obviously wouldn't be better, which is the reason I tried to offer
suggestions for avoiding it.
The only real solution (which needs to scale well) I scan see is,
to provide access e.g. to Macs, to allow a developer to fix the
issue him-/herself.
Yes, good idea !
That of course would be the best solution, but this implies that the
devs would actually look for the errors themselves. Having a Mac around
and nobody caring about it will not help much either...
Sure, having the Mac around is just a prerequisite to ease portability.
And certainly should be used.
[...]
By the way, it would be nice, to offer a buttom to retrigger
tinderbox builds, and certainly a buildbot would be nice as well.
If the tree is dirty (i.e. there were commits after the last build
started), the cws will be rebuilt automatically. If the build failed, it
will be rebuilt after 7-10 days (to have a log available, since old logs
get removed from the sever).
This is IMHO quite a long time, what are the reasons not to rebuild it
directly after changes have been commited? May be Utilization? (I am
more or less a fan of "continuous integration :-)
So not sure what you have in mind when requesting a retrigger function.
You cannot commit and build immediately anyway (since tinderbox slaves
use anoncvs and that has a slight delay in syncing).
This delay is AFAIK about 30-60 minutes, which IMHO is somewhat smaller
than 7 days and could just be regarded as the timeout for changes. I
mean, a rebuild would be triggered earliest 60 m after the latest check
in. In case of any later check in, the build would be aborted and again
restarted after another 60 m. I think you get what I mean.
buildbot is currently enhanced to send the logs to tinderbox, so when
this is done, you can trigger a buildbot build and have the logs on
tinderbox.
Sounds good.
But again: Why would a retrigger be necessary? A build will take 3-4
hours or longer, so you're surely not sitting right next to it and wait
for it to finish... Most likely you will go home before it finished :-)
Yes, but this is still a difference compared to 7 days. Anyway, if I
understand you right, you suggest to just re-trigger builds on the
buildbots , instead of having a button in EIS. Which is fine for me as
well, as long as I can somehow influence that tinderbox status actually
reported in EIS.
[...]
ciao
Christian
Regards
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
