Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

• rust upgrade / releng update
• Submodule update guidelines
  • Where do changes from an upstream master go? Do they need review?
  • Where do servo-specific changes go if there is an upstream master? Servo branch?
  • During a rust upgrade, should we always create a branch on the mozilla-servo repo and merge into the appropriate branch at the time that we're merging into servo/master? (IMO, that makes the most sense —Ms2ger)
• typed units of measure in rust-geom: https://github.com/mozilla-servo/rust-geom/pull/35
  • design bikeshed (newtype struct vs. phantom types?)
  • naming bikeshed (PagePx vs. ContentPx vs. ...)
• SpiderMonkey upgrade?

• jack: A bit of bad news. The rust upgrade requires a newer clang than we have on the builders, so we can't build LLVM there. The releng team is not interested in fixing this because it means a separate build infrastructure for Servo vs. FxOS.
• manishearth: why do we need to build LLVM? Can we just take the package from apt?
• jack: That'll work on Debian. Maybe we have packages for RHEL which we run on the build machines? But it would require changing the build system to use system LLVM, and even if it works now it'll break when Rust needs a newer LLVM. The Linux builders work fine now, but on the Mac builders we need a newer OS X devtools to get a newer clang, and we need a newer version of Mac OS X to get the newer devtools (they are currently on Mac OS X 10.7). So we're going to switch to a non-Mozilla-releng infrastructure, likely Travis CI, but there's a bunch of work required, including changing the build system to use precompiled rustc snapshots (like Rust's bootstrap system). It's unclear what this means for bors, but I think Travis CI has a nice API that will support our current infrastructure. In fact, hopefully it'll even be able to build speculatively as soon as you submit a PR, like for the Rust project. The bad news is, this'll take several days of work and is blocking the Rust upgrade. Our options are to close the tree until this work is done, or to let the Rust upgrade bitrot and then rebase it when we're ready (my preference).
• pcwalton: Or we can maintain a branch without automated tests in the interim. We can periodically do merges and tests on our local machines. That way we can still land on master, and we still have full automation coverage, but the rust upgrade will stay alive on a branch with bitrot / test rot prevention.
• jack: Maybe a better intermediate plan is to disable Mac tests on bors for now, and rely on Linux automation plus local developers' Macs until we have Mac automation back online.
• kmc: I have a spare Macbook that I can devote to that.
• Manish: I have a way of making snapshots very easily; I just need hosting.
• jack: The snapshots are the easy part; the hard part is the build system change.
• Manish: The build system already has a flag to use a precompiled Rust path.
• jack: But it can't auto-download the snapshot (which we'd need for automation). Even if all that is done, moving to Travis and the associated paperwork may take some time.
• Manish: I have Travis integration working here: https://travis-ci.org/Manishearth/rust/ https://travis-ci.org/Manishearth/rust/builds/25499478 (for Rust). I can try it for Servo todayish.
• mbrubeck: lars wasn't so concerned about automating the download, but about where to store the builds, etc.

• jack: For repos we created (like rust-geom) we can just work on master. But for repos forked from an upstream, what I've done is delete the master branch in our clone. We should be working on the servo branch. In an upgrade, generally you would merge upstream master into our servo branch, and then append any additional fixes needed to get it to work with our changes. Any changes that apply to upstream should be submitted upstream; we have committers on all those projects who can land those commits and/or work with the (very responsive) upstream authors to get them reviewed.
• jack: During a rust upgrade, what we've done in the past is create a branch in a personal repo named with a date. But this makes it tedious for other people to "check out" the rust upgrade to test or work on it. Ms2ger and others have started adding branches to the central mozilla-servo/* repos instead. I think we should codify this practice. It would be nice if someone would document this in the wiki ("How to do a Rust upgrade") with a checklist to go through.
• mbrubeck: I can create a wiki page based on these meeting notes; will ask if I have questions.
• jack: If you happen to find any stray "master" branches in repos with upstreams, make sure it gets deleted and servo is set as the default branch.

• jack: I think jdm is just looking for initial feedback; trying to think if anyone but me would be best to do that.

• jack: As for newtypes versus phantom types, while the rust-geom type signatures are hairy, the user code looks pretty good currently.
• pcwalton: That's fine with me.
• jack: Using macros to generate all the trait impls... I don't like that is month. In general, that's what Rust generic types are for. Since the complexity is pretty contained in rust-geom and shouldn't need much ongoing work, it seems like a reasonable cost.
• pcwalton: Yes, that's fine.
• jack: I think the rust-geom patch can land now, and the servo one needs to be rebased and some issues fixed.
• mbrubeck: i'm planning to add some more aliases to help with readability on servo side. i just pushed some tests to rust-geom as well. on the newtype vs. phantom type thing, I sketched out a comparison on Friday and it ended up a bit uglier than the phantom version. If anyone feels strongly about it still, I think we'd need to look at a concrete counter proposal.
• mbrubeck: one thing we haven't discussed is where the units that everything works in. maybe we should figure out if we want to do something more with App Units or transform layers. i hope that this should be just tagging existing code with compile time information.