similar to: Clarification on expectations of buildbot email notifications

I think we could/should be a little bit more precise here: > ... any regressions whether they affect buildbots or not, the > patch author should be responsible for fixing the issue. especially if we say that the bar for a revert is low. That is, the "any regression" needs a bit more clarifications. Assuming we are talking about performance regressions (not language conformance or

Reid said: > 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

This is kind of what I was getting at with my original email, so thank you for wording it better than I did. If we can agree that "contact the author first for internal bots" is better than "revert automatically, even for internal bots" (which may not be the case, I don't want to speak for others), then the problem becomes one of defining what an "internal bot"

On Tue, Sep 1, 2020 at 3:57 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Sep 1, 2020 at 12:42 PM Nico Weber <thakis at chromium.org> wrote: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org>

+1 to Justin's comment The only standard for revert should be: it's broken, and here's a reproducer.  Nothing else should matter. ... says the person w/a ton of internal regression testing which regularly finds crashes upstream, and is terrified of the implied effort of having to engage each author of a broken patch individually while being unable to ship or see what other

On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi, >> >> llvmbb's job is to inform people of build breaks. However, it seems to >> trigger for a big list of bots, and at least one of them seems to always be >>

On Tue, 2015-09-29 at 14:29 -0500, Hal Finkel wrote: > [+Bill and Bill] > > ----- Original Message ----- > > From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > Sent: Tuesday, September 29, 2015 12:39:02 PM > > Subject: [llvm-dev] Fwd: buildbot failure in LLVM on

This buildbot looks like it's been failing since Friday - does anyone know/own/care about it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Mon, Sep 28, 2015 at 7:29 PM Subject: buildbot failure in LLVM on clang-cmake-thumbv7-a15-full-sh To: Adrian Prantl <aprantl at apple.com>, Cameron Esfahani <dirty at apple.com>, Chris Bieneman

Folks, David has been particularly militant with broken buildbots recently, so to make sure we don't throw the baby with the bath water, I'd like to propose some changes on how we deal with the emails on our *current* buildmaster, since there's no concrete plans to move it to anything else at the moment. The main issue is that managing the buildbots is not a simple task. It requires

On 6 December 2014 at 00:03, Benjamin Kramer <benny.kra at gmail.com> wrote: > Reverted for now. Not sure what's going on there. Sorry for the breakage. No worries, at least that was easy to spot. Huzzah for buildbots! :) cheers, --renato

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

+dvyukov On Wed, May 13, 2015 at 11:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > >> It's a 20m timeout without output. >> >> If you back up to the build and look at the 'annotate' step output, >> there's this text: >> >>

I tried to land a small fix before going on vacation at the end of the year, but I had to revert it because it broke on a few of the build bots, specifically clang-cmake-thumbv7-a15, clang-cmake-armv7-a15, and llvm-hexagon-elf. https://reviews.llvm.org/D41264 It seemed to work as expected on the others. Unfortunately, the build logs don't give many clues. The fix included a new test, and

Happened to me again: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/18273/steps/annotate/logs/stdio In fact, this whole bot has a 20% failure rate with the same failure mode, from looking at the history: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/?numbuilds=50 They all end with this: [100%] Running ThreadSanitizer tests -- Testing: 258 tests, 16 threads --

On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > It's a 20m timeout without output. > > If you back up to the build and look at the 'annotate' step output, > there's this text: > > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/annotate/logs/stdio > > -- Testing: 258 tests, 16 threads -- >

Just received this: The Buildbot has detected a new failure of llvm-ppc-linux on llvm. Full details are available at: http://google1.osuosl.org:8011/builders/llvm-ppc-linux/builds/3229 Buildbot URL: http://google1.osuosl.org:8011/ Buildslave for this Build: nick1 Build Reason: Build Source Stamp: 84759 Blamelist: ofv BUILD FAILED: failed compile Apparently the problem was a warning at

So, I broke a few build modes with a recent commit (r266002). I had been developing with clang in debug mode, which worked and passed tests fine. But upon committing, I discovered that I had broken: 1) Bots building with GCC. (fixed subsequently in r266011) 2) Bots doing an NDEBUG build with -Werror. (fixed subsequently in r266016) 3) Bots building llvm with msan. (fixed via revert r266062)

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the