[llvm-dev] Clarification on expectations of buildbot email notifications
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 20 20:20:06 PST 2019
+1 to what Chandler and Reid said
On 2/20/19 2:11 AM, Chandler Carruth via llvm-dev wrote:
> On Tue, Feb 19, 2019 at 1:29 PM Reid Kleckner via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> I don't think whether a buildbot sends email should have anything
> to do with whether we revert to green or not. Very often,
> developers commit patches that cause regressions not caught by our
> buildbots. If the regression is severe enough, then I think
> community members have the right, and perhaps responsibility, to
> revert the change that caused it. Our team maintains bots that
> build chrome with trunk versions of clang, and we identify many
> regressions this way and end up doing many reverts as a result. I
> think it's important to continue this practice so that we don't
> let multiple regressions pile up.
>
> I think what's important, and what we should, after this
> discussion concludes, put in the developer policy, is that the
> person doing the revert has the responsibility to do their best to
> help the patch author reproduce the problem or at least understand
> the bug.
>
> This can take many forms. They can link directly to an LLVM
> buildbot, which should be self-explanatory as far as reproduction
> goes. It can be an unreduced crash report. If they're nice, they
> can use CReduce to make it smaller. But, a reverter can't just say
> "Revert rNNN, breaks $RANDOM_PROJECT on x86_64-linux-gu". If they
> add, "reduction forthcoming" and they deliver on that promise, I
> think we should support that.
>
> In other words, the bar to revert should be low, so we can do it
> fast and save downstream consumers time and effort. If someone
> isn't making a good faith effort to follow up after a revert, then
> authors have a right to push back.
>
>
> I really strongly endorse this approach. This, IMO, is the crux of
> revert-to-green: somewhat regardless of the source of green vs. red,
> we need to revert quickly and with relatively low bar. The result of a
> revert is a shared obligation between reverter and author to find a
> path forward and Reid nicely outlines how the reverter can address
> their end of the bargain.
>
> I want to emphasize that "quickly" here often (but definitely not
> always) needs to be much shorter than "a few days" or even "a day" due
> to the rate of incoming patches and the need to minimize compound
> failures hiding precise regression signal.
>
> Anyways, +1 =]
> -Chandler
>
>
> I agree with Paul that we should remove the text about checking
> nightly builders. That suggestion seems a bit dated.
>
> On Tue, Feb 19, 2019 at 11:22 AM Zachary Turner via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> Hi all,
>
> Over the past year or so, all of us have broken the buildbots
> on many occasions. Usually we get notified on IRC, or via an
> buildbot email notification sent to everyone on the blamelist.
> If I happen to be on IRC I'll see the notification, but if
> not, the next best thing is an email that was automatically
> sent to me (along with everyone else on the blamelist) from
> the buildbot with information about the failure.
> And then finally, I'll occasionally get a response to my
> commit message telling me that it's broken, and the patch may
> be reverted with information in the commit message explaining
> which bot was broken and providing a link to it.
>
> However, we have some buildbots on the public waterfall which
> are specifically configured not to send emails to people. In
> some cases it's because the bots are experimental, but there
> are a handful where the reasoning I've been given is that it
> "wastes peoples time and contributes to build blindness", but
> we are still expected to keep them green (usually by people
> manually reaching out to us when they fail, or patches getting
> reverted and us getting notified of the revert).
>
> It is this last case that I'm concerned about, as it appears
> to be in direct conflict with our own developer policy
> [https://llvm.org/docs/DeveloperPolicy.html#id14], which
> states this
> -----
> We prefer for this to be handled before submission but
> understand that it isn’t possible to test all of this for
> every submission. Our build bots and nightly testing
> infrastructure normally finds these problems. A good rule of
> thumb is to check the nightly testers for regressions the day
> after your change. Build bots will directly email you if a
> group of commits that included yours caused a failure. You are
> expected to check the build bot messages to see if they are
> your fault and, if so, fix the breakage.
>
> Commits that violate these quality standards (e.g. are very
> broken) may be reverted. This is necessary when the change
> blocks other developers from making progress. The developer is
> welcome to re-commit the change after the problem has been fixed.
>
> -----
>
> I'm sending this email to get a sense of the community's views
> on this matter. If I'm correctly reading between the lines in
> the above passage, buildbots which do not send emails should
> not be subject to the revert-to-green policy. To be honest,
> it's actually not even clear from reading the above passage
> where the burden of fixing a "broken" patch on a silent
> buildbot lies at all - with the patch author or with the bot
> maintainer.
>
>
> Would anyone care to weigh in with an unbiased opinion here?
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/165a4cf9/attachment.html>
More information about the llvm-dev
mailing list