Agenda

next work week: 9/22-9/26
Goals visible to office of CTO (as opposed to roadmap, which assumes infinite people)
Q3 (End Sept.): Writing modes, Android + an APK, browser shell
Q4 (End Dec.): Basic dogfooding, optimized graphics pipeline
Couple of blog posts
Devtools possibilities (https://gist.github.com/jdm/35f647cfd63bf665350e)
ICE blocking SM upgrade
(brson) Rust ww 8/18

Next work week

jack: It will be the week of Sept. 22nd. Probably SFO.
kmc: On a train!
jack: I'll see what I can do.
jdm: I will send whatever emails are required for that.
jack: Trans-siberian train?
zwarich: I'm sure the internet connectivity on the train would be pretty bad...
kmc: jdm seems to keep doing amazing stuff on a train!

Goals

jack: andreas (our CTO) has given us a goals spreadsheet for all of the projects. He is keeping track of goals. Ours are writing modes, android build and a basic APK, and a browser shell for Q3, which is the end of september (just after the workweek). For q4, we have basic dogfooding, which is open-ended on purpose, and a graphics pipeline, because that's when the bulk of our work from our graphics pipeline is supposed to land. He is around until the end of January at least.
jdm: Can we be more clear on dogfooding? Because if we want iframes, we need to be more clear and specific to keep them working.
jack: I agree. It's hard because we would like to do github to do basic work tasks, but I don't know how we're going to do it without forms or content-editable.
pcwalton: We need forms to be dogfoodable.
jack: Need wikipedia.
pcwalton: We are really not far from wikipedia. There are just a few layout bugs lingering. I am serious, it's just some layout bugs.
jack: I don't think our Q4 goal can be something we already almost meet...
pcwalton: Q4 should have something with forms.
jack: We will look at the roadmap and replan accordingly. Maybe reddit, hacker news, etherpad (since we use it to do our job). Dogfoodable is that we can use it.
zwarich: Content-editable is going to be a nightmare. I don't know of an implementation of it that isn't a scary mess...
jack: We're going to have the best content-editable ever if we want to dogfood!
zwarich: Content-editable, and animated gifs!
gw: Would github imply https support?
kmc: Yes.
pcwalton: Definitely required for dogfooding, even above forms.
jack: It's already on the Q4 roadmap.
kmc: Probably not going to have a rust TLS impl in Q4 this year
pcwalton: Somebody should revive our bindings.
larsberg: I know they have basic support in rust-http for openssl; we can just turn it on.
jack: It's insecure, but at least it's a first step.
kmc: If security is a goal, we should probably not use a vulnerable image parser, an 18 month old spidermonkey, etc.
jack: There are also blog posts on the list. For people writing those, I sent mail. mbrubeck's went up on the research blog site today. jdm and kmc will have one in August.

devtools

jdm: There has always been a thing in the roadmap saying "devtools" in Q4. The link in the gist is an http server that can connect to devtools. We can integrate that into servo and then we will connect to the firefox devtools. Then, we could write servo-specific devtools for our firefox branches to get useful output from servo. Then, we could write dev tools using javascript frontends and just pump it out using the protocol.
jack: If I knew all I had to do was put ridiculous things in the roadmap and they would happen, I'd do that more often!
pcwalton: That sounds fantastic!
jack: You will make a PR turning that gist into something we can all use? If so, then I will play with that.
jdm: It's nice because the wire protocol structures are just Encodeable Rust structures. There's a lot of reverse-engineering of firefox JS protocols.
jack: Need anything from anyone?
jdm: Just keep in mind things you would like to expose, make a wiki page, or something.
jack: Is the SpiderMonkey memory perf stuff we talked about exposable through this?
jdm: I believe the dev tools team is working on mem profiling tools, so we could probably hook in with that.
jack: Because njn is working on getting Servo memory profiling going, which is awesome.
brson: Is there any benefit from getting Rust itself to speak the firefox debugging protocol?
jdm: I think it's pretty browser-specific.

SpiderMonkey upgrade problem

jdm: Heads-up for people deciding priorities for Rust. There is an ICE blockign the SpiderMonkey upgrade. As far as I know, ms2ger said he made pnkfelix aware of it, but I haven't heard any further results, and it's blocking us.
pcwalton: None of us are working on ICEs, but since it's blocking an upgrade, I will look at it tomorrow.
jack: Bug number?
jdm: I'll get one.
jack: Please add to notes when you find it.

Rust ww

brson: There will be a Rust workweek on the week of August 18th. Who from the Servo team plans to come?
pcwalton: me
jack: I'll be in town anyway, so I will be there part of the time. But don't worry about me for hotel or travel.
brson: Assume it's in SF. If not, then you won't come?
jack: Maybe I can sneak to MTV.
zwarich: I might go, if it makes sense, since I've been doing Rust compiler stuff at the moment. And language changes.
larsberg: I will be talking at LinuxCon that week. But anybody can go, and just represent Servo's interests in issues that affect us - don't have to be deep in all of the workweek issues.
kmc: I can be there if it's in the bay area.
brson: If anybody decides later, please e-mail me in the next day or two. Thanks!

Travis CI

jack: Any questions about it?
brson: Are we paying?
larsberg: Not right now. They are giving us awesome support and machines. But for Servo-specific features, we need to either contribute them or sponsor one of their external contractors.
brson: That's cool they're giving us so much for free.
larsberg: We're kind of a big deal.
jack: I'm planning to rewrite bors so that we get back our r+ thing that we used to have. And the nice bors status queue.
larsberg: I'm working on a real android cross builder, so every few days we'll be making sure that it's building at least.

Interns

jack: Laleh will be starting next Monday. Larsberg is her mentor, and she will be working on mobile battery issues.
brson: Which office?
jack: SF.
jdm: DevTool that maps power usage!
jack: Excellent idea!

Servo memory usage

ryanc: it seems like we have a sound problem. I have a one quick question. Is there a way to measure the memory usage of servo as a whole and each component in servo?
ryanc: and yes, we can hear you.
jack: We have a mozilla engineer, Nicholas Nethercote, who is starting working on that this week. We should have more later this week. The strategy will be to use jemalloc debugging on Linux for the Rust portion and SpiderMonkey profile for JS information.
pcwalton: We could get OSX profiling if we upgrade Rust, too. The first thing Nick can do is find out how much is used by JS/SpiderMonkey.
jack: Skia probably uses its own allocator. We will have to write some glue code to ensure everything is getting tracked.
pcwalton: For upstream components used by Firefox - like Skia - that code already exists and we just need to use their solutions in Servo.
gw: I am doing freetype allocators today, so I can do the Skia ones while I'm at it.
ryanc: we just need to get some quick numbers. in that case, is there any external tools that can do that?
jack: We may have some quick numbers later this week. I will ask Nick later this week, and will also ask what external tools he recommends. He is the person who wrote the javascript memory profiling for rust (and lead the Firefox MemShrink effort). I will ask him to send preliminary results to the mailing list so everyone can see them.
ryanc: ok
jack: Anything else?
ryanc: that's about it. thanks