On 13-06-17 05:57 PM, Graydon Hoare wrote:
Hi,
As part of preparation for 0.7 (due around the end of june / early july)
we're going to be closing the tree for a while, fixing the lingering
breakage that's snuck through 'auto' and accumulated on 'master', and
greatly widening the 'auto' coverage such that this stuff doesn't build
up anymore.
For now, bors is turned off and the tree is closed. Fear not though:
this should ultimately improve life for everyone. More coverage, better
differential testing, less chasing ghosts.
Thanks for your patience. It'll be back asap (along with a snapshot!)
Update on this:
- The tree is open again (has been since thursday)
- There are a whole lot more auto-builders now
- Some are slower. Cycle time is (at least) 2h now, where it
was formerly closer to 30 minutes. Valgrind is now in the loop,
as is a cross-build. These two are the slowest configs.
- They are not _as slow_ as they appeared at first; partly that
was them warming up (building LLVM) and/or bring overloaded,
taking as much as 5h. The successful runs now are 2h.
- I believe we can get cycle time way down. I'd appreciate patience
while we do this. Reverting to the previous arrangement meant
we lost developers to bisection and burning-tree quests, which
is even more frustrating than waiting on slow builds.
- Especially this week: we're in pre-0.7-release mode and this is
a Very Bad Time to be destabilizing stuff.
Ways to adapt:
- Some of the overloading is limited on real hardware, not EC2. We
are waiting on some new minis to arrive. Yell at apple to let
us virtualize OSX on clouds.
- You may want to test a little more thoroughly before queueing
stuff up. The queue is long and the habit of treating a PR as a
smoketest is ... less rewarding now than it might have been.
- You will also benefit from merging / batching trivial changes,
for the time being. If you think you see 3 or 4 PRs that can
be combined into one, doing so is a way you can help out.
- Furthermore: bors happens to fail-to-run much more often when
the queue is long (it fails when github has an API failure);
so if you are _willing_ to merge PRs or take them out of the
queue to wait until it's moving faster, or you have time to
repair them (if they're bad or bitrotted), that'll help.
- There are a lot of really bad codegen problems I will be making
an effort to organize into bugs for people to work on soon.
- I'm going to be spending today trying to adjust buildbot to
ensure it overloads machines less often and cuts off builds
that are redundant when it sees a failure. Daniel seems to have
been doing this manually over the weekend but it needs automation.
Thanks again for everyone's patience. I remain convinced that having
automatic integration is worth much more than a free-for-all on the
tree, but I realize staring at slow build and test cycles is a very
trying experience for us all.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
