Depends on who/what you want to make the decision about which to rollback, but sure.
-
-
Replying to @stephentyrone
The new one, that doesn't work. The old one worked, otherwise it would also have been rolled back. Merge one at a time, only commit if it works. It's a serializer. Simplest form of concurrency control, doesn't need any analysis.
3 replies 0 retweets 17 likes -
Replying to @graydon_pub @stephentyrone
This does kinda fail at the scale of Rust and Firefox, though, with changes landing faster than CI. The solution is rollups and integration branches respectively, but both require some degree of human intervention.
4 replies 0 retweets 2 likes -
Replying to @ManishEarth @stephentyrone
Ooh, snappy answers: 1. There have been multiple successful automated batching strategies, from "try all combinations" to "optimistic bisect-backoff" to various in-betweens. 2. Testsuites typically parallelize perfectly, or should. Engineering mis-spend to not exploit that.
2 replies 0 retweets 10 likes -
What kills me about this discussion (and I've been having it off-and-on for nearly 20 years!) is the willingness orgs display to underinvest in this extremely-high-order bit with respect to their own productivity and QA. It's like "nah we don't want to bother installing plumbing"
1 reply 1 retweet 25 likes -
"We'll just deal with everyone hiking miles to go fetch water, and getting cholera every few days and so forth. We've managed our hydration and sanitation this way a long time, and plumbing is _so_ much work to install!"
1 reply 1 retweet 20 likes -
Replying to @graydon_pub @stephentyrone
Oh, yeah, to be clear I *vastly* prefer the "never break master" CI model, more pointing out that it has scaling issues that are tricky -- not impossible -- to deal with
1 reply 0 retweets 4 likes -
In Rust's case I wrote up an autobatching scheme years ago, requiring a straightforward three way PR classification, but doing it well requires more CI budget than we have right now. Probably could deploy a simpler version of it that gets us some wins.
1 reply 0 retweets 4 likes -
Replying to @ManishEarth @stephentyrone
I mean I'm nowhere near the purse strings but this has literally been an issue off-and-on since I .. uh .. left the project. We were having an argument over it that very week. It means prioritizing cycle time in a way that seems to resist all rational planning. I don't get it.
1 reply 0 retweets 4 likes -
Like if someone with the correct authority said "we don't do any more feature work or bug fixing or anything until cycle time is down to 10 minutes", it would get solved. It's not like compilers that bootstrap and self-test that fast (without $infinite_aws_bill) can't be written.
2 replies 0 retweets 10 likes
I’m fine with investing in automatic rollups (the fact that we have to do them bugs me too), but you lost me at “stop all feature/bug fix work until the compiler is 10x faster”.
-
-
Replying to @pcwalton @graydon_pub and
I’m not even convinced it’s possible for Rust to compile that fast without simplifying the language a lot. Even if it were, you’re talking about a complete rewrite of major subsystems. Like either “rewrite the whole typechecker” or “rewrite LLVM”.
2 replies 0 retweets 8 likes - 12 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.