Perhaps make release the default target for ./mach build, with a servobuild thing so that devs can make the default debug again? For all other cases, have `--release` and `--debug` as flags.
This way people trying it out get the smooth servo experience, but devs can continue to use fast compiling debug builds. I like the token builder idea. Have it build Servo and a subset of the tests. If we can easily get more buildslaves then perhaps we can make it more robust. A slightly different proposal: set up buildbot builders for debug (or release), and have builds for those triggered daily instead of per-PR. This way we don't double our build times or need extra buildslaves. -Manish Goregaokar On Tue, Feb 24, 2015 at 7:42 PM, Lars Bergstrom <larsb...@mozilla.com> wrote: > Two questions about build flavors. > > 1) Should we change the default build type back from debug to release? > > When we made the switch to cargo, we changed to debug builds by default, > which made for some good “reduced build times” headlines, but has gotten me > mail from externals evaluating Servo asking why it’s so slow/choppy. It has > also tripped up internal folks doing performance or memory profiling more > than once. > > 2) Should the builders test release only or release and debug? > > We had release-only regressions during the last set of Rust and submodule > upgrades, which is really bad (e.g., right now, Servo release on OSX does > not display any content!). The only question in my mind here is whether we > want to test everything in release+debug, just test release, or mainly test > release but have a token debug build/test machine. > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
