[llvm-dev] buildbot failure in LLVM on clang-native-arm-cortex-a9

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 26 09:43:24 PDT 2015


On 08/26/2015 09:38 AM, Renato Golin wrote:
> On 26 August 2015 at 17:30, Philip Reames <listmail at philipreames.com> wrote:
>> To say this differently, we will revert a *change* which is problematic.
>> Why shouldn't we "revert" a bot?
> I don't disagree, just don't want to do that lightly. Most certainly
> not before we have comments from the bot owner.
Why?  This is not our policy for commits; why should it be different for 
bots?  Comments within a reasonable time window (2 hours?) sure, but an 
unresponsive owner can simply re-enable when they get around to it.  
Just like the commit author can re-apply at a later time.
>
>
>> As an illustrative example, I submitted some documentation changes earlier
>> this week and got 5 unique build failure notices.  In this case, I ignored
>> them, but if that had been a small code change, that would have cost me at
>> least an hour of productivity.
> I have to say, I never spent more than a few minutes looking up
> failing bots. If there's nothing that I can find in 30 seconds of
> looking at the bot screen, I rely on the bot owners to ping me, revert
> my patches, let me know what's wrong.
The key point I was trying to make was the interruption factor.  Not all 
of the notices come it at once.  If I could batch process, it would take 
a lot less time.

Also, there are simply some usability issues; finding the actual build 
error on a small screen - from a phone while in a meeting say - is 
rather challenging.  I usually end up having to move to a laptop before 
being able to identify something as a false positive.
>
> I'll make your words, mine:
>
>> If all bot owners were doing this, having a unstable list which doesn't
>> actively notify would be completely workable.  If not all bot owners are
>> doing this, I can't say I really care about the status of those bots.
> :D
>
> cheers,
> --renato



More information about the llvm-dev mailing list