On Fri, Aug 14, 2009 at 4:27 PM, Tim Steele<[email protected]> wrote:
> I like the idea of closing the tree automatically more often.  Especially
> for rookies like me, reacting early and consistently is a way lower stress
> way to be sheriff than permitting redness.
> Two days drinking the pkasting kool-aid on the front line and I know that I
> will run a tight ship the next time duty calls :)
> On Fri, Aug 14, 2009 at 12:29 PM, Amanda Walker <[email protected]> wrote:
>>
>> While bot health is separate from tree health, I'm not sure we really
>> want to tolerate redness because a bot is sick--it'll still keep us
>> from noticing regressions or bustage in a timely fashion.  However, a
>> way to visually distinguish between "build failure" and "bot failure"
>> would be nice.  "out of disk space" should be easy to detect--is there
>> any reliable way to detect purify running out of RAM, or other bot
>> failure modes we know about?
>
> Last week there were these weird timeout issues with 'compile sandbox' on
> some of the bots, like Modules Vista; not sure what was happening there.
>  But it was one of the few things we let slip through, so I remember it.
>

Buildbot glossary:
Builder = column in the waterfall
Slave = a machine connected to a builder.
So s/bot/slave/

By definition, slave failures are unpredictable. If they are
predictable, it must be fixed anyway. :)

I'll update http://dev.chromium.org/developers/tree-sheriffs once the
"ignore builder" functionality exists.

M-A

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to