<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:49 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 5 October 2015 at 22:28, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> These buildbots normally finish under one hour, but most of the time<br>
>> under 1/2 hour and should be kept green as much as possible.<br>
>> Therefore, any reasonable noise<br>
><br>
> Not sure what kind of noise you're referring to here. Flaky fast builders<br>
> would be a bad thing, still - so that sort of noise should still be<br>
> questioned.<br>
<br>
</span>Sorry, I meant "noise" as in "sound", not as opposed to "signal".<br>
<br>
These bots are assumed stable, otherwise they would be in another<br>
category below.<br>
<span class=""><br>
<br>
> I'm not sure if we need extra policy here - but I don't mind documenting the<br>
> common community behavior here to make it more clear.<br>
<br>
</span>Some people in the community behaves strongly different than others. I<br>
sent this email because I felt we disagree in some fundamental<br>
properties of the buildbots, and before we can agree to a common<br>
strategy, there is no consensus or "common behaviour" to be<br>
documented.<br>
<br>
However, I agree, we don't need "policy", just "documented behaviour"<br>
as usual. That was my intention when I said "policy".<br>
<span class=""><br>
<br>
> Long bisection is a function of not enough boards (producing large revision<br>
> ranges for each run), generally - no? (or is there some other reason?)<br>
<br>
</span>It's not that simple. Some bugs appear after several iterations of<br>
green results. It may sound odd, but I had at least three this year.<br>
<br>
These are the hardest bugs to find and usually standard regression<br>
scripts can't find them automatically, so I have to do most of the<br>
investigation manually. This takes *a lot* of time.<br></blockquote><div><br></div><div>Flakey failures, yes. I'd expect an XFAIL while it's under investigation, for sure (or notifications forcibly disabled, if that works better/is necessary). Because flakey failures produce un-suppressable noise on the bot (because they're not a continuous run of red).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Generally all bots catch serious bugs.<br>
<br>
That's not what I meant. Quick bots catch bad new tests (over-assuming<br>
on CHECK lines, forgetting to specify the triple on RUN lines) as well<br>
as simple code issues (32 vs 64 bits, new vs old compiler errors,<br>
etc), just because they're the first to run on a different environment<br>
than the developer uses. Slow bots are most of the time buffered<br>
against those, since patches and fixes (or reverts) tend to come in<br>
bundles, while the slow bot is building.<br>
<span class=""><br>
<br>
>> like self-hosted Clang<br>
>> mis-compiling a long-running test which sometimes fails. They can<br>
>> produce noise, but when the noise is correct, we really need to listen<br>
>> to it. Writing software to understand that is non-trivial.<br>
><br>
> Again, not sure which kind of noise you're referring to here - it'd be<br>
> helpful to clarify/disambiguate.<br>
<br>
</span>Noise here is less "sound" and more "noisy signal". Some of the<br>
"noise" in these bots are just noise, others are signal masquerading<br>
as noise.<br>
<br>
Of course, the higher the noise level, the harder it is to interpret<br>
the signal, but as it's usual in science, sometimes the only signal we<br>
have is a noisy one.<br>
<br>
It's common for mathematicians to scoff the physicists lack of<br>
precision, as is for them to to the same to chemists, then biologists,<br>
etc. When you're on top, it seems folly that some people endure large<br>
amounts of noise in their signal, but when you're at the bottom and<br>
your only signal has a lot of noise, you have to work with it and make<br>
do with what you have.<br>
<br>
As I said above, it's not uncommon the case where a failure "passes"<br>
the tests for a few iterations before failing.</blockquote><div><br></div><div>That would be flakey - yes, there are many sources of flakeyness (& if it passed a few times before it failed, it probably won't fail regularly now - it'll continue to oscillate back and forth over passing and failing, producing a lot of notification noise/spam). Flakeyness should be addressed, for sure - XFAIL or suppress bot notifications while investigating, etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So, we're not talking<br>
*only* at hardware noise, but also at the code level, which had<br>
assumptions based on the host architecture that might not be valid on<br>
other architectures. Most of us develop on x86 machines, so it's only<br>
logical that PPC, MIPS and ARM buildbots will fail more often than x86<br>
ones. But that's precisely the point of having those bots in the first<br>
place.<br>
<br>
Requesting to disable those bots because they generate noise is the<br>
same as asking people to give their opinion about a product, show the<br>
positive reviews, and sue the rest.<br></blockquote><div><br></div><div>When I suggest someone disable notifications from a bot it's because those notifications aren't actionable to those receiving them. It's not a suggestion that the platform is unsupported, that the bot should be turned off, or that the issues are not real. It is a suggestion that the notifications are only relevant to the owner/persons invested on that platform, and that a level of triage from them may be necessary or otherwise appropriate.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> But they are problems that need to be addressed, is the key - and arguably,<br>
> until they are addressed, these bots should only report to the owner, not to<br>
> contributors.<br>
<br>
</span>If we didn't have those bots already for many years, and if we had<br>
another way of testing on those architectures, I'd agree with you. But<br>
we don't.<br></blockquote><div><br></div><div>I'm not suggesting removing the testing. Merely placing the onus on responding to/investigating notifications on the parties with the context to do so. Long blame lists and flakey results on inaccessible hardware generally amount to unactionable results except for the person who owns/is invested in the architecture.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree we need to improve. I agree it's the architecture specific<br>
community's responsibility to do so. I just don't agree that we should<br>
disable all noise (with signal, baby/bath) until we do so.<br></blockquote><div><br></div><div>If the results aren't actionable by the people receiving them, that's a bug & we should fix it pretty much immediately. If the architecture specific community can then produce automated actionable results, great. Until then I don't think it's a huge cost to say that that community can do the first level triage.<br><br>In cases where the triage is cheap, this shouldn't be a big deal for the bot owner to do so - and when the triage is expensive, well, that's the point: imposing that triage on the community at large (especially with large blame lists), doesn't seem to work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By the time we get there, all sorts of problems will have crept in,<br>
and we'll enter a vicious cycle. Been there, done that.<br></blockquote><div><br></div><div>Why would that happen? All I'd expect is that you/others watch the negative bot results, and forward any on that look like actionable true positives. If that's too expensive, then I don't know how you can expect community members to incur that cost instead of bot owners?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> I still question whether these bots provide value to the community as a<br>
> whole when they send email. If the investigation usually falls to the owners<br>
> rather than the contributors, then the emails they send (& their presence on<br>
> a broader dashboard) may not be beneficial.<br>
<br>
</span>Benefit is a spectrum. People have different thresholds. Your<br>
threshold is tougher than mine because I'm used working on an<br>
environment where the noise is almost as loud as the signal.<br>
<br>
I don't think we should be bound to either of our thresholds, that's<br>
why I'm opening the discussion to have a migration plan to produce<br>
less noise. But that plan doesn't include killing bots just because<br>
they annoy people.<br></blockquote><div><br></div><div>Again: if the notifications are going to people who can't act on them, we should disable them, otherwise people will not have confidence in the positive signals and we are lacking value overall.<br><br>Disabling the bot is not the only solution - simply disabling the notifications for contributors, having them go to the bot owner first for triage, then they can forward the notification on to the contributor if it's a good true positive. I assume bot owners are already doing this work - if they care about their platform presumably they're watching for platform-specific failures and often having to follow up with contributors because so many of them ignore the mails today because of the unactionable nature of them. So I'm not really asking for any more work from the owners of these bots, if they care about the results & people are already ignoring them.<br><br>I'm just asking to remove the un-actioned notifications to increase confidence in our notifications.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you plot a function of value ~ noise OP benefit, you have a surface<br>
with maxima and minima. Your proposal is to set a threshold and cut<br>
all the bots that fall on those minima that are below that line. My<br>
proposal is to move all those bots as high as we can and only then,<br>
cut the bots that didn't make it past the threshold.<br></blockquote><div><br></div><div>The problem with that is that people continue to lose confidence in the bots (especially new contributors) the longer we maintain the current state (& I don't have a great deal of confidence in the timespan this will take to get automated high quality resulrts from all the current bots). Once people lose confidence in the bots, they're not likely to /gain/ confidence again - they'll start ignoring them and not have any reason to re-evaluate that situation in the future. That's my usual approach, but recently decided to re-evaluate that & be verbose about it. Most peolpe aren't verbose (or militant, as you put it) because they're already ignoring all of this. That's a /bad/ thing.<br><br>I would like to set the bar high: that bot notifications must be high quality, and if they aren't, that we disable them aggressively. This places the onus on the owner to improve the quality before turning the notifications (back) on. Rather than incurring a distributed cost over the whole project (that may have a long term effect) while we wait for the quality to improve. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> So to be actionable they need to have small blame lists and be reliable (low<br>
> false positive rate). If either of those is compromised, investigation will<br>
> fall to the owner and ideally they should not be present in email/core<br>
> dashboard groups.<br>
<br>
</span>Ideally, this is where both of us want to be. Realistically, it'll<br>
take a while to get there.<br>
<br>
We need changes in the buildbot area, but there are also inherent<br>
problems that cannot be solved.<br>
<br>
Any new architecture (like AArch64) will have only experimental<br>
hardware for years, and later on, experimental kernel, then<br>
experimental tools, etc. When developing a new back-end for a<br>
compiler, those unstable and rapidly evolving environments are the<br>
*only* thing you have to test on.<br>
<br>
You normally only have one of two (experimental means either *very*<br>
expensive or priceless), so having multiple boxes per bot is highly<br>
unlikely. It can also mean that the experimental device you got last<br>
month is not supported any more because a new one is coming, so you'll<br>
have to live with those bugs until you get the new one, which will<br>
come with its own bugs.<br>
<br>
For older ARM cores (v7), this is less of a problem, but since old ARM<br>
hardware was never designed as production machines, their flakiness is<br>
inherent of their form factor. It is possible to get them on a<br>
stable-enough configuration, but it takes time, resources, excess<br>
hardware and people constantly monitoring the infrastructure. We're<br>
getting there, but we're not there yet.<br>
<br>
I agree that this is mostly *my* problem and *I* should fix it, and<br>
believe me I *want* to fix it, I just need a bit more time. I suspect<br>
that the other platform folks feel the same way, so I'd appreciate a<br>
little more respect when we talk about acceptable levels of noise and<br>
effort.<br></blockquote><div><br></div><div>I'm sorry if I've come across as disrespectful. I do appreciate that a whole bunch of people care about a whole bunch of different things. Even I fall prey to the same situation - the GDB buildbot is flakey. I let it go but I really should fix the flakes - and I wouldn't mind community pressure to do so. But partly, as I mentioned in my previous reply, existing noise levels make it not as interesting to improve small amounts of noise (tragedy of the commons, etc). The lower the noise level, teh more important/pressure we'll have to keep the remaining sources of noise down.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> I disagree here - if the bots remain red, they should be addressed. This is<br>
> akin to committing a problematic patch before you leave - you should<br>
> expect/hope it is reverted quickly so that you're not interrupting<br>
> everyone's work for a week.<br>
<br>
</span>Absolutely not!<br>
<br>
Committing a patch and going on holidays is a disrespectful act. Bot<br>
maintainers going on holidays is an inescapable fact.<br>
<br>
Silencing a bot while the maintainer is a possible way around, but<br>
disabling it is most disrespectful.<br>
<br>
However, I'd like to remind you of the confirmation bias problem,<br>
where people will look at the bot, think it's noise, silence the bot<br>
when they could have easily fixed it. Later on, when the owner gets to<br>
work, surprise new bugs that weren't caught will fill the first weeks.<br>
We have to be extra careful when taking actions without the bot<br>
owners' knowledge.<br></blockquote><div><br></div><div>I'm looking at the existing behavior of the community - if people are generally ignoring the result of a bot anyway (& if it's red for weeks at a time, I think they are) then the notifications are providing no value. The bot only provides value to the owner - who triages the failures, then reaches out to the community to provide the reproduction/assist developers with a fix.<br><br>All I want to do is remove notifications people aren't acting on anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> I'm not quite sure I follow this comment. The less noise we have, the /more/<br>
> problematic any remaining noise will be<br>
<br>
</span>Yes, I meant what you said. :)<br>
<br>
Less noise, higher bar to meet.<br>
<span class=""><br>
<br>
> Depends on the error - if it's transient, then this is flakiness as always &<br>
> should be addressed as such (by trying to remove/address the flakes).<br>
> Though, yes, this sort of failure should, ideally, probably, go to the<br>
> buildbot owner but not to users.<br>
<br>
</span>Ideally, SVN errors should go to the site admins, but let's not get<br>
ahead of ourselves. :)<br>
<span class=""><br>
<br>
>> Other failures, like timeout, can be either flaky hardware or broken<br>
>> codegen. A way to be conservative and low noise would be to only warn<br>
>> on timeouts IFF it's the *second* in a row.<br>
><br>
> I don't think this helps - this reduces the incidence, but isn't a real<br>
> solution.<br>
<br>
</span>I agree.<br>
<span class=""><br>
<br>
> We should reduce the flakiness of hardware. If hardware is this<br>
> unreliable, why would we be building a compiler for it?<br>
<br>
</span>Because that's the only hardware that exists.<br>
<span class=""><br>
<br>
> No user could rely on it to produce the right answer.<br>
<br>
</span>No user is building trunk every commit (ish). Buildbots are not meant<br>
to be as stable as a user (including distros) would require.</blockquote><div><br></div><div>I disagree with this - I think it's a worthy goal to have continuous validation that is more robust and comprehensive. At some point the compute resource cost is not worth the bug finding rate - and we run those tasks less frequently. But none of that excuse instability. I'd expect infrequent validation to be acceptably less stable than frequent validation.<br><br>Extra validation before release is for work that takes too long (& has a lower chance of finding bugs) to run on every change/frequently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> That's<br>
why we have extra validation on releases.<br>
<br>
Buildbots build potentially unstable compilers, </blockquote><div><br></div><div>Potentially - though flakey behavior in the compiler isn't /terribly/ common. It does happen, for sure. More often I see flakey tests/test infrastructure - which reduces confidence in the quality of the infrastructure, causing people to ignore true positives due to the high rate of false positives.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">otherwise we wouldn't<br>
need buildbots in the first place.<br>
<span class=""><br>
<br>
>> For all these adjustments, we'll need some form of walk-back on the<br>
>> history to find the previous genuine result, and we'll need to mark<br>
>> results with some metadata. This may involve some patches to buildbot.<br>
><br>
> Yeah, having temporally related buildbot results seems dubious/something I'd<br>
> be really cautious about.<br>
<br>
</span>This is not temporal, it's just regarding exception as no-change<br>
instead of success.<br></blockquote><div><br></div><div>red->exception->red I don't mind too much - the "timeout->timeout" example you gave is one I disagree with.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The only reason why it's success right now is because, the way we're<br>
setup to email on every failure, we don't want to spam people when the<br>
master is reloaded.<br>
<br>
That's the wrong meaning for the wrong reason.<br>
<span class=""><br>
<br>
> I imagine one of the better options would be some live embedded HTML that<br>
> would just show a green square/some indicator that the bot has been green at<br>
> least once since this commit.<br>
<br>
</span>That would be cool! But I suspect at the cost of a big change in the<br>
buildbots. Maybe not...<br></blockquote><div><br></div><div>Yeah, not sure how expensive it'd be.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>> This is a wish-list that I have, for the case where the bots are slow<br>
>> and hard to debug and are still red. Assuming everything above is<br>
>> fixed, they will emit no noise until they go green again, however,<br>
>> while I'm debugging the first problem, others can appear. If that<br>
>> happens, *I* want to know, but not necessarily everyone else.<br>
><br>
> This seems like the place where XFAIL would help you and everyone else. If<br>
> the original test failure was XFAILed immediately, the bot would go green,<br>
> then red again if a new failure was introduced. Not only would you know, but<br>
> so would the auhtor of the change.<br>
<br>
</span>I agree in principle. I just worry that it's a lot easier to add an<br>
XFAIL than to remove it later.<br></blockquote><div><br></div><div>How so? If you're actively investigating the issue, and everyone else is happily ignoring the bot result (& so won't care when it goes green, or red again) - you're owning the issue to get your bot back to green, and it just means you have to un-XFAIL it as soon as that happens.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Though, it might be just a matter of documenting the common behaviour<br>
and expecting people to follow through.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>