Servo Meeting 2014-04-07

Agenda

Official Mozilla module owner (jdm) http://www.mozilla.org/hacking/module-ownership.html
Discussion of Q2 goals & plan (https://etherpad.mozilla.org/servo-planning and https://github.com/mozilla/servo/wiki/Roadmap )
Rust upgrade (ms2ger)
Should we use that status update tool? None of us really do anymore. Who reads it?
Web Platform Tests - status and how should we integrate running them? (manishearth, ms2ger, jgraham)
- (Manishearth) I may turn up a bit late, a quiz of mine got rescheduled to an hour before the meeting.
Build system options (mach vs. makefiles vs. cmake, etc.) (larsberg, jack) https://github.com/mozilla/servo/issues/2046

Attending

jack, mbrubeck, larsberg, simonsapin, jgraham, azita, jdm, ms2ger, kmc, abinader, Manishearth

Module ownership

jdm: As I said in e-mail, creating an official module for Servo is a good thing to show that we have a governance structure and are tied in to Mozilla as a whole. I'm open to debate that.
mbrubeck: I've done this before, and the goal was not to change what the team was doing, but just to document it.
jack: Azita, did you have any concerns about this?
azita: It seemed in the mails that you were nominating dherman, is that right?
jack: I think originally it was myself and patrick. Then jdm thought maybe Dave...
azita: dherman's out this week, and he should be here if so. But it's up to you guys. I don't think dherman cares.
jdm: My impression is that dherman has some reponsibility for Servo? i.e., that he's the top in the chain for decision? But maybe jack or patrick?
mbrubeck: Module owner is two things. 1: someone who can make decisions. 2: someone who can determine who the peers are and when to pass on module ownership. Sometimes those are different people, etc.
azita: Is it usual to have more than two? Seems confusing. Or is that something that happens?
jdm: For some of the larger modules, yes. Or when you have people who are sharing the role in different aspects.
mbrubeck: Some parts of gecko (ipc & indexdb) have three.
azita: Then, just have jack, pcwalton, and dherman?
jack: Let's wait until dherman gets back. If he is, then we can propose it next week.
azita: If it's not urgent, then let's just leave this off until next week.
jack: I'm sure we'll get feedback from others if we're doing it wrong.

Q2 goals

jack: Two documents. One is the roadmap and one is the servo planning etherpad. The Q2 goals on the roadmap are pretty much everything we'd already gone over. The planning etherpad has a basic overview of details and tentative owners. So, the first question is: does this list look correct for Q2? Beyond that, we can talk about what individual people want to work on.
jack:
jack: Not sure what's blocking an android buildbot. I think releng said they wouldn't spend any cycles on it, so it's up to us. What's the status of android builds?
lars: Broken. Need to fix something in cross-target configuration; keep getting it working just in time for a new rust upgrade that breaks it.

Testing notes

simonsapin: We don't need to separate the tests by w-p-t vs CSS, but instead script vs. CSS and tests that we want to contribute back. Also, bidi is not as important as the rest of writing modes, because it's fairly independent of the rest of layout code.
jack: Isn't the problem with the CSS WG tests that they're not ref tests?
simonsapin: In the CSS 2 suite, many of them are not automatic. So, yes, ideally we should eventually convert them to reftests. But, that will be a lot of work. Some are ref tests already. And the CSS level 3 specs may have better tests.
jgraham: In CSS level 3, they only accept ref tests unless it is impossible to write them. It may be harder because they have their own infrastructure. Once we have compelling infrastructure in the w-p-t, we will try to import all of the CSS tests there as well. So, I'm hoping that it will eventually be a solved problem, but that might not occur on your timescale. Certainly, it will not likely happen in the next three months.
jack: Is is worthwhile to have them make the tests pass even if they're not automatic? Or should converting them to reftests be OK?
jgraham: Convering some will be trivial, but for some it is definitely not. If it's easy to convert to a ref test, it's worth doing. Because if we just get it to pass once, nobody will notice when it breaks again.
simonsapin: We should probably start with the automatic ones.
jack: The goal was to have easy first projects for the interns, so we would have to look and see why the tests don't pass.
jgraham: Looking at a random selection of tests, they do not generally look like they are hard to convert to reftests.
jack: Then I will make that part of the initial projects. We may have to filter out the ones that look like they may be hard to convert.
jgraham: The other problem is that you need to know which basic features do work to build the reference part of the test...

Missing planning items

jack: drmaeo; nightly builds. Also some new things: layers revamp, switching to SDL or EFL, and headless X testing support. Oh, and some misc. build system stuff, too. Does anyone have strong opinions on these things that aren't yet on the roadmap?
jdm: Getting the CSS OM might be important to support basic web apps. but maybe we just need the style property?
jack: Yeah, it didn't seem particularly hard, but it also seemed like we'd have to build some of the CSSOM infra to do it. Setting style does a bunch of stuff internally that requires the full CSSOM implementation. This came up in the longcat demo for the summit - changing the background color dynamically did not work. Maybe it'd be a good intern project?
jdm: Or a superstar contributor?
jack: Great, so should we keep the roadmap up to date with these names? Should we have people-names on the items in the list, file bugs and have owners?
jdm: I like issues.
jack: OK, lars and I will edit the roadmap wiki and we'll get some issues filed. Any other roadmap/planning issues?
azita: Do we have metabugs, like one for Q2?
jack: Probably just individual things, but linked from the roadmap wiki.
simonsapin: I don't think BIDI affect the rest of layout the way writing modes does. It's mostly about text. So maybe not as urgent as writing modes? Maybe don't need for Q2?
jack: OK, let's move it out.

Rust upgrade

jack: How far forward are we going?
jdm: Last Saturday.
jack: Anything we need to talk about on it? Except that it's being done? I saw submodules landing.
jdm: There's a problem with MutexArc's replacement having requirements we can't fulfill.
jack: WIll that change?
jdm: There's something filed. I think there was discussion over the weekend and eddyb mentioned a bug... (#13125)
jack: Previously, we just copied the rust stdlib things and named them stuff like NewRc. So, we can just copy the old one over and deal with it in the next rust upgrade when that gets fixed. I seem to recall ms2ger didn't like that idea... maybe because the current MutexArc is unsafe.
larsberg: Something about needing Share+Send and just being Send...
jack: wasn't that the point of MutexArc?
jdm: At minimum we should voice our problem in the issue; someone who understands the ramifications, preferably.
jack: I think copying and pasting is a reasonable solution for now.

Status update

jack: Should we use it? My response is "yes" and I try to read it.
mbrubeck: the smedberg one? (http://benjamin.smedbergs.us/weekly-updates.fcgi/ )
larsberg: I'd just brought it up because it'd become any every-other-thing deal
azita: It's useful for me to understand what's going on.
jack: Super-helpful for me to also see the history for someone over the last few months to remind me of what it looked like. I vote in favor of nagging for weekly entries. Maybe a wiki page for new contributors/employees/interns that tells them what the team uses. Certainly would be nice to have ms2ger and the rest using the tool so we know what they're hacking on :-)
azita: Just not have it in multiple places. I find that one to be very useful.
jack: The alternative is status more in meetings, which I'd like to avoid.

Web platform tests

jack: So, where are we currently? I know jgraham did some work to get the runner working. Do we need to update?
jgraham: General status is that in theory it now works with Servo. I tried it and it did work a few days ago. Also, the code now all lives in mozilla-central. A bit unfortunate, but it's also going to become a PyPy package so you can install via 'pip install'.
simonsapin: What's the name of the package?
jgraham: wpt-runner. It should now be possible to run them. But, integrating them into the build process or workflow is not entirely straightforward. We don't expect every test in the repository to pass. So, what the tool does is it allows you to create manifest files that tell you the expected result of the tests that don't pass. And so, every time you re-import the upstream tests, you need to regenerate those manifest files so they're correct for any changes that happened in the tests. There's a tool in there that pulls in upstream tests, but I think you have to decide where this is going to live in the Servo Universe. With gecko, it's in-tree, copies the tests over and commits them into mozilla-central. It then commits the manifest files. Basically, you then do a dry run with the new versions of the tests to get the new results. So, we need something equivalent in Servo.
jack: MAybe have the wpt tests be a submodule? And then just have the manifest in the Servo repo?
jgraham: The tests could, and then you could ignore the update infrastructure. It does have an autogeneration manifest tool...
jack: Updating the manifest can just be part of updating the submodule pointer.
jgraham: You'd have to update the expected baselines, anyway. Other practical problems are that there are a lot of them and they take a long time to run. In Gecko with one process, it takes an hour (serial). So it's not completely clear you want to make this happen when you type make check.
jack: We can make this part of the make check targets and just have it run by the bots. So you can do it yourself if you want to, but only the bots always do. Our turnaround time on the bots is only 10 minutes, so this would be a big regression in serial. In parallel, probably only 10-15 minutes, which is fine.
jgraham: It can run them in parallel, though I suspect they will be less stable. Initially, my approach would be to take a minimal set that you have a hope of passing and explicitly list what you want to run. There's no point in indexdb, DOMRange, etc. since we don't even support them. It would immediately cut down what we have to run by an order of magnitude.
jack: Sounds fine. Manish, any questions?
manish: No questions! Running the individual tests is better than running them all at once. I don't know about the submodules because it will require git to run properly. Also, having the tests inside the build directory, the update tool does not work correctly.
jgraham: Yes, the tools assume the mozilla-central model if they're in a git repository, which is not what we want.
jack: So we just don't run the update tool?
jgraham: You just don't use it to do the sync. I think if you use a submodule, you don't need it.
manish: Yes, just use the submodule and update it manually instead of via the normal wpt scripts. Otherwise, things will break.
jack: OK, great. Anything else on wpt?

Build systems

jdm: mach is not an either/or. mach is a level above makefiles, cmake, etc. It can create build backends. It's a meta-meta-build engine.
jack: What are the common things you do with mach?
jdm: It gives you a framework for building nice tools to aid developers. IT's a python package on pypi (don't have to borrow from firefox). Things that are useful in Firefox include integrating a build-system-configuration thing that sets up everything you need. Mach also determines when a clobber is required and will stop the build and tell you what to do. It also records warnings; shows resouce utliization. It's a broad python system for integrating lots of small modules that do things that you want. The resulting build files are just python scripts with very limited environments (lists of files, it automatically determines parallelism, etc.)
jack: ms2ger says it's nicer to interact with than makefiles?
jdm: Yes. mach help gives you info
jack: Other things use it than firefox?
jdm: Nope.
jgraham: You could be the first!
jack: Some of them sound nice. ninja will list make targets (like how rake -t works). If we use CMake + ninja, that would give it to us. But CMake also generate Makefiles, which still have this problem...
jdm: Can have backends that generate files for ninja, tup, etc.
larsberg: How much are we talking about in terms of having a "mach person" writing scripts and files and stuff?
jdm: We don't have that many requirements, so it shouldn't be too challenging to create the moz.build files that mach uses... but they don't have git submodules
mbrubeck: We could do what firefox did with mach, where it's just a wrapper that runs make commands. But then, you're also talking about using mozbuild, which is a second part of the firefox build system, and rewriting our Makefiles in to moz.build files... just using mach to wrap things is simple. The mozbuild is potentially more involved.
jack: Yeah, I think we're not ready to rewrite to firefox's build system. We can look into mach then. jdm, you and mbrubeck and ms2ger have the most experience. Have you done any of this mach work before?
jdm: Not recently, but I have in the past.
jgraham: I've done non-build-related things with mach, which maybe doesn't count.
jack: Do you like it?
jdm: Yes. Very.
mbrubeck: Yes.
jack: Second part of this item is that the plan of record was to redo the build with cmake. Some of this was to get something that worked on Windows easily, because we'd previously been thinking about doing Windows soon. Not clear that Windows is such a high priority. So, do we want cmake? Are we happy with what we have now for Q2? Just looking for people's thoughts there.
jdm: sounds like "meh"
jack: Okay, is anybody having PROBLEMS with our build system?
crickets
jack: I know build systems are polarizing, but opinions are welcome...
jdm: I have no issues with what we have, so let's stay with this for now.
jack: One caveat is it would be nice if we could manage submodules better, particularly with the unintentional clobbers during Rust upgrades

ACID2

simonsapin: I think there's a non pixel-perfect bug. We don't scroll to pixel perfect position w.r.t. jumping to #top because we have anti-aliasing issues.
jgraham: So we can't reftest against the PNG
jack: I feel comfortable with having passed layout correctly. Neither Safari nor nightly pass...
mbrubeck: ACID2 does not work on HIDPI or zoomed. Nightly should pass on standard display and zoom level 100%. https://bugzilla.mozilla.org/show_bug.cgi?id=580920#c5
jack: I'll draft a blog post without the scroll position bugfix.
azita: We still have 24 bugs open for ACID2. Are we going to close these?
jack: I think most can be closed. jdm and some others have been closing them, but we haven't made a concerted effort to go through that.
azita: Yes, the list of bugs grows over time. With Rust, we had to have a separate weekly meeting just to triage them.
SimonSapin: It's valuable to have ACID2 as a reftest and multiple occasions, it was the only one that would fail when there was a bug in layout. Admittedly, the weasyprint test suite is not that good, but it's a pretty good test.
jack: Certainly. ACID1 has caught more than a few already, too.