<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 7, 2015 at 3:10 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">Hi David,<br>
<br>
I think we're repeating ourselves here, so I'll reduce to the bare<br>
minimum before replying.<br>
<span><br>
<br>
On 6 October 2015 at 21:40, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> When I suggest someone disable notifications from a bot it's because those<br>
> notifications aren't actionable to those receiving them.<br>
<br>
</span>This is a very limited view of the utility of buildbots.<br>
<br>
I think part of the problem is that you're expecting to get instant<br>
value out of something that cannot provide that to you. If you can't<br>
extract value from it, it's worthless.<br></blockquote><div><br></div><div>Not worthless - just not valuable (negative value, actually - because it drowns out other signals) to me, and, by extension, probably people like me (I assume most other random contributors).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, it seems, you're associating community buildbots with company<br>
testing infrastructure.</blockquote><div><br></div><div>Sorry if it came off that way - I'm not sure what I said to imply that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> When I worked at big companies, there were<br>
validation teams that would test my stuff and deal with *any* noise on<br>
their own, and only the real signal would come to me: 100% actionable.<br>
However, most of the bot owners in open source communities do this as<br>
a secondary task.</blockquote><div><br></div><div>Sure - I own the GDB 7.5 buildbot in this fashion currently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This has always been the case and until someone<br>
(LLVM Foundation?) starts investing in a better infrastructure overall<br>
(multi master, new slaves, admins), there isn't much we can do to<br>
improve that quick enough.<br>
<br>
The alternative is that the less common architectures will always have<br>
noisier bots because less people use them day-to-day, during their<br>
development time.</blockquote><div><br></div><div>They will have more to say - but that shouldn't mean low signal/noise. But, yes, if developers aren't acting on the results because they don't know how to (they can't reproduce the issue without hardware, for example) then it's not a useful signal for them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> By having a hard line on those, in the long run,<br>
means we'll disable most testing on all secondary architectures, </blockquote><div><br></div><div>Again, I'm not suggesting disabling testing. I'm suggesting notifying those people who are the ones generally taking action on these results. Which, it sounds like, are you & other people with a specific vested interest in that platform.<br><br>Am I misunderstanding that? Are many of the unique failures reported by these bots directly acted on by community members who committed the change?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and<br>
LLVM becomes an Intel compiler. But many companies use LLVM for their<br>
production compiler on their own targets, so the inevitable is that<br>
they will *fork* LLVM. I don't think anyone wants that.<br></blockquote><div><br></div><div>I'm not sure how that follows for a variety of reasons. (for one: those people forking would need to own/maintain/triage/filter their own test infrastructure results - so if they can do that internally, they can do that externally)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I'm not suggesting removing the testing. Merely placing the onus on<br>
> responding to/investigating notifications on the parties with the context to<br>
> do so.<br>
<br>
</span>You still don't get the point. This would make sense on a world where<br>
all parties are equal.<br>
<br>
Most people develop and test on x86, even ARM and MIPS engineers. That<br>
means x86 is almost always stable, no matter who's working.<br>
<br>
But some bugs that we had to fix this year show up randomly *only* on<br>
ARM. That was a serious misuse of the Itanium C++ ABI, and one that<br>
took a long time to be fixed, and we still don't know if we got them<br>
all.<br>
<br>
Bugs like that normally only show up on self-hosting builds, sometimes<br>
on self-hosted Clang compiled test-suite. These bugs have no hard<br>
good/bad line for bisecting, they take hours per cycle, and they may<br>
or may not fail, so automated bisecting won't work. Furthermore, there<br>
is nothing to XFAIL in this case, unless you want to disable building<br>
Clang, which I don't think you do.<br></blockquote><div><br></div><div>If it's broken and continues to be broken, what's the point in continuing to build it? If that step could be XFAIL'd while you or whomever was investigating such a failure continues to investigate, that seems like exactly the right behavior.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While it's taking days, if not weeks, to investigate this bot, the<br>
status may be going from red to green to red.</blockquote><div><br></div><div>You mean this is a flaky failure - an inconsistent reproduction?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It would be very<br>
simplistic to assume that *any* greed->red transition while I'm<br>
bisecting the problem will be due to the current known instability. It<br>
could be anything, and developers still need to be warned if the alarm<br>
goes off.<br></blockquote><div><br></div><div>Do they? If the odds are reasonable that it isn't their problem, telling them about it is hurting the project in other ways (& yes, not telling them about real problems is hurting the project too, I realize).<br><br>What I don't want is to distribute the cost of that unreliable reproduction to everyone in the community (not even the original committer, since we don't know who that is, but everyone in the community who commits code). I would like flaky issues specific to a certain architecture/hardware/bot to be owned by that bot owner - since it's likely that no one else can really investigate them effectively.<br><br>And the cost of that is that the bot owner then also has to manually triage failures during that period - I don't find this to be a high cost and I do this for the GDB bot anyway (I get mail on every failure - I inspect them all, and if they look like a genuine true positive due to debug info, I follow up with the commit and check that the author is aware of it - if my bot stopped sending blame mail today (which wouldn't be an unreasonable request - it has a moderately high flake rate with GDB tests timing out) it wouldn't cost me anything - I'm already doing what's necessary there)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The result may be it's still flaky, the developer can't do much, life<br>
goes on. Or it could be his test, he fixes immediately, and I'm<br>
eternally grateful, because I still need to investigate *only one* bug<br>
at a time. By silencing the bot, I'd have to be responsible for<br>
debugging the original hard problem plus any other that would come<br>
while the bot was flaky.<br></blockquote><div><br></div><div>No, you wouldn't - you'd be responsible for a first level triage, which, if the flake rate is moderate, you've already imposed on many more people by asking them to triage these flakes rather than you - and they have less context (they don't know what current flaky issues there are, or how they manifest - so the community as a whole may end up investing several duplicate efforts to understand that flake as people assume that it's their fault - or they don't, and they get in the habit of ignoring buildbot results (from your builder - even when the flakes have gone away: this hurts you, or from all builders - this hurts the community as a whole))</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now, there's the issue of where does the responsibility lies...<br>
<br>
I'm responsible for the quality of the ARM code, including the<br>
buildbots. What you're suggesting is that *no matter what* gets<br>
committed, it is *my* responsibility to fix any bug that the original<br>
developers can't *action upon*.<br></blockquote><div><br></div><div>No - it is your responsibility to get them to a place where they can act upon it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That might seem sensible at first, but the biggest problem here is the<br>
term that you're using over and over again: *acting upon*. It can be a<br>
technical limitation that you can't act upon a bug on an ARM bot, but<br>
it can also be a personal one. I'm not saying *you* would do that, but<br>
we have plenty of people in the community with plenty of their own<br>
problems. You said it yourself, people tend to ignore problems that<br>
they can't understand, but not understanding is *not* the same as not<br>
being able to *act upon*.<br>
<br>
For me, that attitude is what's at the core of the problem here. By<br>
raising the bar faster than we can make it better, you're essentially<br>
just giving people the right not to care.</blockquote><div><br></div><div>They already have that right - and I believe are exercising it regularly. Is your experience different? Are most (>90%) of the uniquely reported issues on your buildbot addressed by the original committer without your assistance?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The bar will be raised even<br>
further by peer pressure, and that's the kind of behaviour that leads<br>
to a fork. I'm trying to avoid this at all costs. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
> All I'd expect is that you/others watch the negative<br>
> bot results, and forward any on that look like actionable true positives. If<br>
> that's too expensive, then I don't know how you can expect community members<br>
> to incur that cost instead of bot owners?<br>
<br>
</span>Another example of the assumption that bot owners are validation<br>
engineers and that's their only job.</blockquote><div><br></div><div>No, that's not my assumption - my assumption is that bot owners have the most context for their bot & can provide triage (knowing the common flakes, failure modes, false positives, etc - because they see them all, rather than once every few months), reproduction steps, logs, etc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It was never like this in LLVM<br>
and it won't start today just because we want to.<br></blockquote><div><br></div><div>It might if that's the only way to contribute a bot - contributing a bot without an owner that can triage/repro/etc the results seems not good to me. If the owner can't do it, why would the expect the community to do that for them?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My expectation of the LLVM Foundation is that they would take our<br>
validation infrastructure to the next level, but so far I haven't seen<br>
much happening. If you want to make it better, instead of forcing your<br>
way on the existing scenario, why not work with the Foundation to move<br>
this to the next level?<br></blockquote><div><br></div><div>Because this is easier for me, potentially. I want to express/encourage/drive towards the appropriate signal/noise for bots so that new contributors (and old) can trust the signal. Then it's up to those who want to contribute bots to meet that bar. Then owners, presented with the real cost of the bots falling to them (which I still think isn't that high - like I said, I triage every GDB 7.5 failure myself already today - that's the right tradeoff for me, if the issues were greater I would invest some time in making it more automated so I wouldn't feel a need to do that (but I know, for example, that the Apple engineers can't look at/run the test cases from the suite, so it needs some help)), can decide whether paying the time/effort/engineering to improve the situation is worthwhile - distributing and duplicating the cost across the project as it is today makes it hard to see the cost and justify the improvement. Each individual decides it's not worth their time to try to push against the status quo or do the work, so nothing happens.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
> Once people lose<br>
> confidence in the bots, they're not likely to /gain/ confidence again -<br>
<br>
</span>That's not true. Galina's Panda bots were unstable in 2010, people<br>
lost confidence, she added more boards, people re-gained confidence in<br>
2011.</blockquote><div><br></div><div>What behavior did you observe that represents the loss/gain in confidence?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then it became unstable in 2013, people lost confidence, we<br>
fixed the issues, people re-gained confidence only a few months later.<br>
This year it got unstable again, but because we already have enough<br>
ARM bots elsewhere, she disabled them for good.<br>
<br>
You're exaggerating the effects of unstable bots as if people expected<br>
them to be always perfect. I'd love if they could be, but I don't<br>
expect them to be.<br></blockquote><div><br></div><div>Not perfect, but a fair bit better than they are - my understanding, anecdotal as it is, is that a lot of people ignore a lot of bots. That's not good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I'm looking at the existing behavior of the community - if people are<br>
> generally ignoring the result of a bot anyway (& if it's red for weeks at a<br>
> time, I think they are) then the notifications are providing no value.<br>
<br>
</span>I'm not seeing that, myself. So far, you're the only one that is<br>
shouting out loud that this or that bot is noisy.<br></blockquote><div><br></div><div>Yep, most people just seem to ignore them except for a handful or when they all explode together (oh, look, I checked in a -Asserts -Wunused-variable build break). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sometimes people ignore bots,</blockquote><div><br></div><div>Sometimes? It's pretty much impossible to commit without getting at least a couple of fail-mails. Seems like that's a lot of mail to ignore (especially from builders that build with coarser granularity than one-build-per-commit, which is most of them).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but I don't take this as a sign that<br>
everything is doomed, just that people focus on different things at<br>
different times.<br></blockquote><div><br></div><div>I don't think everything is doomed - clearly we've survived, released, etc, in this state for a while. I take it as a sign that the system is sub-optimal and I'm trying to make some noise about it where other people resign themselves to auto-bining most of the buildbot results. (see James's reply for another example of someone trying to bring this issue up, failing to get anyone to listen, and giving up/resigning himself to the same outcome)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
>> No user is building trunk every commit (ish). Buildbots are not meant<br>
>> to be as stable as a user (including distros) would require.<br>
><br>
> I disagree with this - I think it's a worthy goal to have continuous<br>
> validation that is more robust and comprehensive.<br>
<br>
</span>A worthy goal, yes. Doable right now, with the resources that we have,<br>
no. And no amount of shouting will get this done.<br></blockquote><div><br></div><div>I'm not shouting at anyone. (& to a degree I think it is achievable, if we consider the costs in the right places - but my suggestion here isn't even necessarily to improve/create that world)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we want quality, we need top-level management, preferably from the<br>
LLVM Foundation, and a bunch of dedicated people working on it, which<br>
could be either funded by the foundation or agreed between the<br>
interested parties. If anyone ever get this conversation going (I<br>
tried), please let me know, as I'm very interested in making that<br>
happen.<br></blockquote><div><br></div><div>I don't think it requires top-level management changes to make changes here. All software is hard & we all work to make different bits of it better, I don't see why that wouldn't be the case here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
> red->exception->red I don't mind too much - the "timeout->timeout" example<br>
> you gave is one I disagree with.<br>
<br>
</span>Ah, yes. I mixed them up.<br>
<span><br>
<br>
>> I agree in principle. I just worry that it's a lot easier to add an<br>
>> XFAIL than to remove it later.<br>
><br>
> How so? If you're actively investigating the issue, and everyone else is<br>
> happily ignoring the bot result (& so won't care when it goes green, or red<br>
> again) - you're owning the issue to get your bot back to green, and it just<br>
> means you have to un-XFAIL it as soon as that happens.<br>
<br>
</span>From my experience, companies put people to work on open source<br>
projects when they need something done and don't want to bear the<br>
costs of maintaining it later.<br>
<br>
So, initially, developers have a high pressure of pushing their<br>
patches through, and you see them very excited in addressing the<br>
review comments, adding tests, fixing bugs.<br>
<br>
But once the patch is in, the priority of that task, for that company,<br>
is greatly reduced. Most developers consider investigating an XFAIL<br>
from their commit as important as the commit itself, but not<br>
necessarily most companies do so with the same passion.<br></blockquote><div><br></div><div>I'm not necessarily suggesting that the developer put the XFAIL in, but you could. You've said you are investigating issues -  so while you are actively investigating the issue, it is expected to fail.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moreover, once developers implement whatever they needed here, it's<br>
not uncommon for their parent companies to move them away from the<br>
project, in which case they can't even contribute any more due to<br>
license issues, etc.<br>
<br>
But we also have the not-so-responsible developers, that could create<br>
a bug, assign to themselves, and never look back unless someone<br>
complains.<br>
<br>
That's why, at Linaro, I have the policy to only mark XFAIL when I can<br>
guarantee that it's either not supposed to work or the developer will<br>
fix it *before* marking the task closed.</blockquote><div><br>Sure - I'm talking about the current situation that seems to be the process you're working with. Failure happens on your bot, you investigate (possibly for hours, days, or weeks) and eventually fix it. I'm suggesting that the correct thing to do is to XFAIL that test (or revert the commit) as soon as you start investigating it (I'm happy enough with a fix in the order of minutes (Oh, look, I used named LLVM IR values, so the test fails on -Asserts - quick fix, no need to XFAIL/revert, then fix, etc) but anything longer than that it seems worth the minute or two it would take to get the build green again)<br><br>This is good for you and the project as a whole - in this way, future failures will actually send mail (the bot will go red again) rather than hiding all the issues until the issue is fixed hours/days/weeks later.<br><br>- David </div></div></div></div>