Reminder: use http://benjamin.smedbergs.us/weekly-updates.fcgi/

• Homu is coming! http://build.servo.org/homu/ (larsberg)
• Feedback desired for https://groups.google.com/forum/#!topic/mozilla.dev.servo/clnLuNRPWcM (jdm)
• Feedback desired for https://github.com/ecoal95/rust-x11-offscreen-rendering-context/ for WebGL project (jdm)
• CSS tests here! (larsberg)

• Manishearth, kmc, jack, larsberg, mbrubeck, brson, pcwalton, SimonSapin, jdm, azita

• larsberg: Just a heads-up: Like Rust we are switching from Bors to Homu. Big advantage is lower-latency responses to PR comments. It will also let us turn on automation for all of our repos using just a single server. Thanks Manish for Python help. The bad news is that GitHub is having some server-side API issues affecting both bors and homu. GitHub staff are looking into it right now. We're seeing things get manually fixed for some of our PRs. Let me know if anything is blocking you; otherwise just continue to r normally.
• jack: How does this integrate with Travis?
• larsberg: For repos with Travis enabled, you can say "r " in a comment, and homu will do the merge after Travis goes green.
• jack: How is the merge handled?
• larsberg: I think it does the equivalent of pushing the green button.
• kmc: So it's possible to r two PRs that pass individually on Travis but fail when both merged?
• Manishearth: Homu queues things up to avoid that.
• larsberg: Once we're ready to flip the switch, I'll send mail to dev-servo. The r comment style changes; instead of the commit, homu looks for comments on the PR itself.
• SimonSapin: Which repos does this affect?
• larsberg: Working on the servo repo now, but we can add any repo with Travis enabled.
• jack: We can't do things like core-foundation easily because Travis doesn't do OS X.
• jack: Will we keep the name bors, bors-servo, or homu?
• brson: Rust's homu install is still called bors.
• larsberg: You have the GitHub account @bors, right? We have @bors-servo.
• brson: You could share @bors if you want.
• larsberg: I'd rather not share credentials unnecessarily, if we can just make a config change. Speaking of credentials, we should probably have a better way of tracking our various config secrets.

• jdm: WebGL canvases for Servo. They will be working it for several months. Posted a request for useful information to dev-servo, but there are no replies yet. If somebody could do so, that would be great, even if just to say, "that is all correct."
• jack: Looks like something you should reply to, pcwalton, because it covers native shared surfaces.
• pcwalton: Can somebody provide the link? Aha, in agenda.
• jdm: Also, there's an X11 repo porting stuff from Gecko. I know so little about this that it would be valuable for somebody else to look into this. Is there prior art?
• jack: We use MESA offscreen rendering, which gw set up in Servo. He would be the best one to review that stuff.
• kmc: OSMESA is not h/w accelerated at all, and will not be useful for WebGL. Probably need a real X11/Cocoa/etc. context.
• jack: Definitely. gw is the right one to talk with about that.
• jdm: Yes, I wanted to know whom to forward requests for feedback to.
• jack: Task is to review the repo? And see if it's the right thing?
• jdm: So far, Emelio and I have been basing our plans on what Gecko does.

• larsberg: jgraham checked in a first version of integration with the CSSWG tests. I'll be going through looking for failures that can be turned into E-Easy bugs. I'll need help verifying that the bugs are actually easy, and not horribly difficult. This should help us get some good starting bugs for layout/style to go along with all the DOM ones we have.
• kmc: This plus gw's document on getting started in layout will help.
• jack: It'd be great if this can help webdevs get involved with Servo and also learn how to read and reason about the specs.
• SimonSapin: There's still some pain with running the tests taking forever.
• larsberg: The upstreaming workflow needs some work too.
• jack: It might be good to go through the process of fixing a single test, as an example we can point new contributors to. We need instructions that go through all the individual mach commands for different common things you want to do.

• jack: Did pretty well last week! Though we then got lots of new contributors and got it back up again. Did anybody not make it to their PRs last week?
• mbrubeck: Still in progress.
• kmc: I have one I still need to review. Others are blocked on other stuff.
• jack: All got their next actions taken, which is what we wanted. Maybe I'll take a look at the end of the day today and maybe do more assigning? Most of the ones today should be easier than the old ones because people will not have disappeared, etc. Or a rust upgrade
• kmc: Speaking of rust upgrade, if we want to switch to piston, we need an update.
• jdm: It's in progress, but there was an ICE.
• pcwalton: Filed upstream? The rust team has more team to work on ICEs, etc. now, since there are no more language or library features.
• jack: Let's get the PR queue down, but an upgrade would be good for the rust team. Also, some people have started contributing the beta update stuff for submodules. A couple have run into things with where they don't know how to get rid of unstable deps. Benchmark tests are unstable because the tests are unstable, so it seems you can't do that. I put in the bug that we should just delete the benchmark tests, since it was just rust-png, and that's going away anyway. If you see anybody doing that, please help them. Hopefully we can get all the submodules onto beta for free.
• simonsapin: Sometimes the benchmarks can just be removed. Otherwise, we can use Cargo things to conditionally compile them.
• jack: For rust-selectors?
• simonsapin: Anything that uses benchmarks we actually want to keep where that is blocking for running on beta.

• SimonSapin: Been moving some libraries to run on beta and publishing on crates.io and using them as deps instead of via git. It makes Cargo a little faster. During the next rustup, you may need to watch for if things are on cargo or github to make sure you're not pulling in two versions of the same thing.
• jack: Cargo needs a lint.
• kmc: Could have a "tidy" for the lock files.
• jack: Could you file an easy bug?
• SimonSapin: Somebody asked about this, but it's a use case to support different versions.
• kmc: It might be what someone wants, but it is generally an error for Servo.
• jack: It's ended up in the past with three versions where we did not want it to happen. It didn't break anything, but they were on different versions of the rust language, so it was actually not a compileable program.
• kmc: Bug #5497 filed. https://github.com/servo/servo/issues/5497

• jack: I saw the repo got created, so I assume you pulled it out of util?
• simonsapin: Yes. It was in the util crate, then moved to rust-selectors, and yesterday I moved it to an independent library.
• jack: Why not in rust upstream?
• kmc: Ours is MPL. libsyntax has one, but it's optimized differently.
• simonsapin: We've been removing stuff from the standard library, not adding them, for the last six months.
• pcwalton: They have to either be marked stable or have to be hellgated, so it's not useful to upstream. We would like type-level numeric literals before stabilizing smallvec anyway, so you don't have to have an enumeration of smallvec types.
• kmc: Ideally, Vec and String could be generic over their storage, which is a good reason not to standardize now.
• simonsapin: Better to have things in crates.io than the stdlib so that we can update them.
• jack: Just making sure there's no underlying Rust issue, like where we're missing DST so we can't do Arc usefully and have horrible workaround we need to remove later.

• azita: All submitted in workday? Needs to be done in the next week or so.
• jack: Doing it!
• larsberg: Ours are submitted.
• azita: Don't want to make things last-minute.