<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 29, 2015 at 10:56 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 29 September 2015 at 18:41, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> Is it? While it's failing, the buildbot doesn't seem to be any use to the<br>
> community at large - it's essentially the buildbot owners problem at that<br>
> point and probably shouldn't be engaging with the community until it's green<br>
> again, I think?<br>
<br>
</span>The bot is useful as it still shows if there are new bugs since the<br>
initial problem, and can help bisect any further problem when they<br>
come. If we disable that bot, when we fix the issue and bring it back,<br>
there could be a number of new failures that we didn't monitor and<br>
that will need a few more days/weeks to remove, especially if they're<br>
cumulative. This way, it's likely that we'll never have that bot<br>
online ever again. This is bad for the community.<br></blockquote><div><br></div><div>The community generally doesn't pay attention to the bot once it goes red - so this seems to be only relevant to the "we didn't monitor" and by "we" I/you mean you-and-other-people-who-care-about-the-bot, not the community at large.<br><br>I certainly don't look beyond "oh, the bot was already red" and /maybe/ if you're lucky "oh, a different thing is failing now", but I often don't get that far owing to the high false positive rate (due to flakes and existing errors) in the buildbots.<br><br>Maybe other people's experiences are different, but I don't have much evidence to suggest that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Is the buildbot useful to you during this time? Or are you debugging<br>
> elsewhere/privately?<br>
<br>
</span>Both. As I described above, this bot is useful not just to me, but the<br>
community, as they can cross check if their commits introduced bugs to<br>
all ARM bots, not just one, and the slow bot will show that.</blockquote><div><br></div><div>I don't know about other people, but I don't cross reference bots that closely. I mostly ignore the low rumble of noise I get back from the buildbots every time I commit. I have to measure by magnitude (& level of trust with different bots) this is really not possible for newer contributors - they won't know what to pay attention to or not. I don't think it's a sustainable way to run the bots.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm also<br>
investigating elsewhere, since if I turn this bot off, what I said<br>
above will happen. I'm also not alone in investigating this, Saleem is<br>
helping me.<br>
<span class=""><br>
<br>
> If the buildbot is useful to you, but not the community at large - perhaps<br>
> we could get in the habit of moving it into a "no email" pool whenever a<br>
> failure occurs, until it can be cleared up. (hopefully this pool is clearly<br>
> distinguished from the rest of the buildbots in the waterfall/grid view -<br>
> because it'd be helpful to be able to look at an easily distinguished subset<br>
> of the waterfall/grid and see the bots that are expected to be green for any<br>
> developer there)<br>
<br>
</span>Any movement means restarting the buildmaster, which means stopping<br>
all current builds and upsetting all other bots. If we start taking<br>
the stance of moving things up and down the priority list, we'll have<br>
more unstable buildbots and that's worse for the community. Our<br>
agreement, at least from what I understood, was that we should move<br>
unstable bots to offline if: they're broken for a while AND no one is<br>
trying to or can fix it. "A while" is vague because it depends on the<br>
hardware, and I'm definitely trying to fix it.<br>
<br>
It's not because the hardware is slow that it has no value to the<br>
community, unless you're arguing that we shouldn't test ARM at all,<br>
which is a whole different story.<br></blockquote><div><br></div><div>If the failure mails are not actionable, they're not useful to the community. If the blame list is too long (or too delayed) it's not likely to be useful.<br><br>If a certain platform just takes a long time (though we could reduce that with a hybrid approach - cross build the compiler on a fast platform, run the tests on the other) then it's necessary to put more hardware (multiple slaves) behind it to reduce the blame lists, I think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not emailing bugs in this bot when it's green means it's probably<br>
useless, </blockquote><div><br>It doesn't seem useless - it's still a signal to you and other developers who care about the platform and will investigate failures.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">so I wouldn't want to have any bots in there. I already have<br>
a separate buildmaster which doesn't email where I test my prototypes,<br>
but those are work in progress, while my production bots are not.<br>
<br>
A neater solution would be to not email *any* buildbot that moves from<br>
exception to failure if the previous non-exceptional status is also<br>
failure. This way, we won't have the kind of email that upset you, but<br>
we still have the value that a red bot provides.<br></blockquote><div><br></div><div>Sure, I'd be OK-ish with that, though it'd still make looking at the waterfall/grid problematic as it is today (though I don't do that often, so I don't personally care about that). It'd be the same as moving the buildbot to a "no email" group until fixed, but without the need to cycle the buildmaster (& with the benefit that it'd happen automatically - though I'm only suggesting moving it off emailing when there's active investigation, so the small manual task at the beginning and end of that cycle doesn't seem too detrimental - no need to do it when someone just checks in a buildbreak by mistake, etc)<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>