Agenda items

Please see dev.servo email about retrying PRs (jdm)
user agent time? (larsberg)
- https://github.com/servo/servo/issues/4331#issuecomment-94798146
e10s status (pcwalton) [deferred to next week]
any webaudio takers? (jdm)

Attending

jack: Seems like most people have read and started marking issues in retries. Please put a reason in. If it's intermittent, either find or open an issue and reference it when performing a retry. That will help us track them down.
jdm: If this causes frustration, we can probably address it. I'm loathe to make tools making it easier.
larsberg: I like that it not being tooled up because it encourages us to keep seeing and fixing it.
jack: Also, one of our mac slaves died last night and I'm going through getting them retried. It's easy to tell when it happened because they fail checking stuff out of git.

larsberg: We had a long thread, gathered statistics. I think it's time to check in a real UA string. On mobile we're getting served plain desktop sites, which makes it difficult to compare on Android vs. any other browser. The risk here is that this will change the content delivered by servers, so there may be instability for a bit as we get wildly different results from the past. I'm open to objections.
mbrubeck: As long as it's switchable on the command line I don't think it matters much.
larsberg: Will make the change after the call.

jack: Should we be testing in debug, too, now?
jack: Yes, asserts.
larsberg: I'd also like to have overflow checking.
mbrubeck: Can also do debug asserts and overflow checking w/ optimizations. May be able to build with opt level 1 and parallel codegen to speed up the build.
jack: We should be alright on linux. Trying to get builders under 30 minutes, which is true for everything but mac3 (test-css). I don't think adding debug to test-wpt will push us over. Release build is our perf issue. Release vs. debug testing isn't a huge difference; more is the number of cores. The biggest we can do on mac is 8 core, we run on 4 right now. I tried on faster cores, but it didn't help much. May switch us to that.
mbrubeck: We should get chunking to work!
jack: Yeah, but I don't know if we want more mac machines...

jdm: I was browsing through the GH network graph related to servo and found interesting things. Diego Marcos has some code that does some very basic WebAudio! He's looking for more time to finish it off, but he's also open to handing it off. I thought I'd bring this up... (https://github.com/servo/servo/compare/master...dmarcos:webaudio-kickoff)
manish: What needs to be done there?
jdm: Implementing all the other node types and a... well, all of it. Lots of infra around having a graph of nodes. There's a library that was written for FF for sound-related things and has a rust wrapper. Lots of the logic...
larsberg: Maybe land it, see how hard the bugs are? If they're good E-Easy bugs, maybe we could ask Diego to help us review?
jack: Is there an awesome site we could get people working towards having functional? Many of the WebAudio filters aren't used, so there's probably some good first steps to get pages working.
jdm: I will talk to Diego.

jack: I'm going to put up public-facing versions of some of the demos. Where should it go? One of our public repos? Do we have a site?
manish: Probably need to make a new site at some point.
jack: New GH repo and a cname?
manish: Yes.
jdm: Servo-experiments.com! I owned it at one point...
jack: If you still have it, we can put it there. It would be nice to have them publicly hosted, since they all require a web server to run them.
larsberg: oooh! Then we could have the linuxcon rust logo + matrix multiple demo that works horribly on all other browsers hosted somewhere :-)
jack: Also, if it's a repo, could get some contributions to our demos.

manish: I'll be working on it. If you have idea on that, let me know!
jack: I believe all the discussion we had before was that we could just use leveldb, write rust bindings, and go with it.
manish: It's what they use in Chrome?
jack: Also gecko for various things...?
jdm: nope, we're sqllite 4 lyfe.
jack: Could go that way as well, but I suspect leveldb would be simpler.
manish: Initially, was planning to do a horrible hashmap, but it makes sense to work on the backend first instead of just the DOM side of things. Any preferences on approaches?
jdm: The DOM-side stuff is easier for people other than you to work on.
manish: I can also leave some stuff unimplemented for good E-Easy bugs.
jack: Also be good to talk to someone on the fxos perf team, as they can probably steer us better. They use Indexeddb for everything on fxos...
larsberg: Except stuff at app startup, which they use cookies for; very good idea to check in with them!