Hi Eric, *,

On Fri, Mar 16, 2007 at 11:17:47AM +0100, eric b wrote:
> Le 16 mars 07 à 09:47, Kay Ramme - Sun Germany - Hamburg a écrit :
> 
> >But, even after I have read the mails, I am not sure how to work  
> >with this respectively to avoid build breakers in practical life.  

<nitpick>
Well, you don't have to avoid buil-breakers. You have to avoid that
a cws with known build-breaker gets integrated...
</nitpick>

> >E.g. I just set my latest CWS to "Ready for QA", despite the MacOSX  
> >being red. I had somewhat a of clue what went wrong, but was not  
> >really able to fix it, as I had no machine at hand. So, my question  
> >is, what is the suggested approach to address such issues? I  
> >currently see three options:
> >-a- ignore it, does not seem to be choice

Very bad...

> >-b- find somebody e.g. with a Mac and ask him/her to look at the  
> >problem

Yes. And that "find somebody" can for example be by using IRC or the
meilinglists.

> >-c- write an issue for the Mac port owner

That should be done in parallel (if at all) since there should be an
action on it in a timely fashion...

> As Mac OS X owner, I just want to say :
> 
> - native port ( without X11) currently in development is our  
> priority, and eats a lot of our resources. People willing to fix X11  
> issues are welcome.

Build breakers are very likely not related to X11 or not and thus will
break the aqua port as well.

> >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)
 
> >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...

> [...] 
> >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).

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).

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. 
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 :-)
 
> [...]

ciao
Christian
-- 
NP: Blind Guardian - And The Story Ends
                           Join #qa.OpenOffice.org on irc.freenode.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to