Skip to content

Meeting 2014 11 17

Jump to bottom
jdm edited this page Nov 17, 2014 · 1 revision

Servo Meeting 2014-11-17

Agenda items

Attending

  • larsberg, jack, simonsapin, cgaebel, manishearth, zwarich, kmc, mbrubeck, azita, brson, mrobinson

Workweek agenda

  • lars: Filled it in with all information we've been getting. Biggest thing is that we have dedicated Servo room on T/W, Th/Fr all Research will be in a room of 65 people. Will focus on scheduling meetings with other groups on those two days. Please come up with further ones, or be prepared to be squishy.
  • azita: Only Rust/Servo in one room, not all Research.
  • jack: We could take advantage of closeness to Rust team and have blocker/post 1.0 discussions as necessary.
  • lars: Such as smartpointer integration with Felix.
  • jack: T/W we only have half day. All-hands things in the mornings with the company. Any discussions with whole group should probably happen on those days. Th/Fr could be small groups on specific projects. Easier to break up and find corners.
  • azita: Jack, will you be meeting with Fabrice, etc?
  • jack: Yep. Don't have to happen in that room.
  • azita: They're in another hotel that's a decent walk away. Consider doing it on T/W when everyone's at the Art Museum already.
  • jack: Everybody take a look at the agenda, think about projects you'd like to work on, add anything you'd like, and we'll take another look next week.

Android

  • lars: Thanks to work by gw and mbrubeck, there's a builder online and verifying that the platform still builds. Coming up: ARM servers in the cloud that we go access to, so hopefully an ARM Linux build that could run reftests and testsuites on the builders themselves. Also ordered a Nexus 9, so working on getting AArch64 support which likely means Rust fixes.
  • jack: Can Rust cross-compile for that yet?
  • larsberg: Nope.
  • zwarich: Shouldn't be hard.
  • jack: Who did the ARM support at Samsung originally?
  • brson: Don't recall exactly. Combination of Seo, Ryan and Yichoi?
  • jack: Could be worth looking into help there.
  • brson: At the workweek they specifically mentioned they have some boards.
  • jack: Can we do the same thing we're doing for ARM32 for the builder?
  • larsberg: No ARM64 servers on the horizon, but we could at least gate the compile. I'm not super worried about the builder support in the next month.
  • kmc: Could set up QEMU chroots for testing.
  • jack: Probably want to make sure there's an Android builder for Rust.
  • zwarich: Problem of QEMU is running tests is super slow.
  • kmc: Haven't used it for big test suites, just build testing, but was pleased with how fast it was in general. It does per-process emulation rather than whole-system. Worth looking into, since it's not hard to make. Debian's schroot can make it out of the box.
  • brson: Rust is already doing Android emulator tests and happy with the speed (pretty slow).
  • zwarich: Thinking of WPT.
  • kmc: Don't think it's essential to run WPT for every architecture. More important just to make sure Servo builds, and run some smoke tests if possible.

CEF 2014 plans

  • zmike: The CEF implementation has been filling out. In upstream, I have about 75% of CEFSimple. Locally, I have more like 95-100% done, but I hit an issue with the latest rustup (as many of you know) currently working to resolve that. After it, I'd like to get coverage tests submitted. It works for testing both ser

  • jack: Do you have a simple test in a branch?

  • zmike: I can share it after the meeting. It doesn't link against anything, but does have some environment requirements. That aside, string encoding I'd appreciate some help with. Simon volunteered... I can create a separate issue for it. It would be great if somebody who knows about encoding could help.

  • simonsapin: I can follow up on IRC.

  • zmike: The way that CEF works is that every string is a CEFString type. There are three types: utf8, utf16, and wide. Any application that uses CEF states what type of string it wants to use, and then CEF does the conversions. We can't detect that - we can detect which methods are being called, but not what structs are being used. We can define the base CEFString methods to hit an environment variable, so that in addition to the #define we can pull from that variable and any embedders have to set that. Any ideas people have, I'll create an issue ticket for that. Aside from that, my goal by the end . cefsimple just shows a webpage, cefclient is more complicated.

  • jack: At the workweek patrick and I worked on some native shells around the CEF stuff. For GTK I have an OpenGL thing that CEF can use but it's not quite ready. The idea is we can get rid of the old one once they're done.

  • zmike: Seems reasonable.

Logo stuff

  • jack: People continue to come up with ideas. Should we contact one? Was there one we liked?
  • larsberg: It would be nice to have a good logo and make some progress on it.
  • azita: Should work internally with Mozilla on the branding, because it's different than Rust. I also just sent mail on this to the Rust team. For 2015, we're budgeting more closely for swag. Don't know who the designer is, if we need an invoice, etc, need to make sure we can afford it.
  • jack: I suspect branding won't care too much, given the gecko logo.
  • larsberg: I have tried to contact branding several times; no response on the logos.
  • SimonSapin: Servo or Mozilla Servo?
  • jack: Don't call it Mozilla Gecko...
  • azita: There are guidelines around fonts and colors. Servo will be different than Rust.

libgreen

  • zwarich: The current situation is that we're using a fork of acrichto's libgreen, moved out of the stdlib. mbrubeck made that happen. We haven't yet moved in Rust, though, to where the old I/O is removed, since it occurred just 7 days ago. By the next upgrade, both the old I/O system and probably libgreen itself (latter is not a problem for us). Dealing with I/O removal, I'm thinking we should probably make all of our I/O threads native threads instead of green, until we determine what we will want to do. This will keep Servo working when we upgrade. We may hit some perf problems, but at least we won't block. For logging, we can either keep the debug logging and aturon says we'll just block the thread while logging or we can switch to libgreen's logging, which will be a cooperative task switching point. I'm tempted to stick with what we have because changing all the logging in servo is a big move. And we probably will want to do something other than libgreen.
  • jack: debug! and info! logging?
  • zwarich: Yes. It still has to work, but I think it's fine if it blocks.
  • cgaebel: Write a nonblocking backend for it?
  • jack: Inside Rust, no?
  • zwarich: Yes. The explicit goal with this work from the Rust team is to make everything map directly to OS I/O facilities.
  • jack: debug! and info! are provided by the prelude, correct? Can we override them?
  • kmc: Yes, definitely.
  • zwarich: Not clear how the macros expand to something that we could override...
  • cgaebel: setlogger function? http://doc.rust-lang.org/log/fn.set_logger.html
  • kmc: Could define your own macros. I though you needed to include the logging crate to get them. If Rust doesn't have a way to override those macros, it's something we should fix for 1.0. And I can look into it as part of my 1.0 work to fix Rust macros.
  • jack: We can stick with the blocking ones for now, as zwarich mentioned.
  • kmc: Seems fine. I don't know about info!, but debug! isn't even compiled in.
  • zwarich: Do we compile in debug! in our release builds?
  • kmc: Just do cargo --release. I think I tried getting debug logging in our release builds and it doesn't work. I know it's configurable, but the default configuration in Cargo doesn't enable logging on release builds.
  • jack: Yes, it looks like we don't have any special overrides and just do the default. Sounds like a good plan. Any bugs for which tasks need to be converted?
  • zwarich: I'll file them after the meeting. I've done a look into them already. One nice thing is that every time we hit a green thread bug, we just ported them to native threads anyway. The loading tasks are, I believe, the only major ones. We will even get to see what it means to have a native thread per resource! Might not be pretty...
  • jack: This upgrade still has the runtime stuff, but the next one won't? Anything else this will break besides I/O and green threads?
  • zwarich: I don't think so. There was this old setlogger mechanism, but I don't think we were using it. I believe that since it was all part of the runtime, it has all been removed. When that happens, we might want to do a rust upgrade as soon as possible. If we delay too long, the next rust upgrade might be a lot of work.

Reviews on Critic

  • SimonSapin: Some reviews on Critic still get messed up. Can we come up with some sort of rule that limits force pushes until the review is done or recommends people do it very carefully? Unfortunately, github does not have hooks that prevent 'bad pushes.'
  • jack: Not sure what to do. I've never had problems with normal rebases, but have never gotten anything interactive to work. But there's no way to prevent it. Every other workflow that people use involve interactive rebases.
  • kmc: git has commit hooks; we could have a client-side hook that checks to see if it's an open PR, and advise you that rebase-i is a Bad Idea.
  • jack: Do we have to get people to install them separately?
  • kmc: Can ship the hooks with the repo, but have to run a script to make them live.
  • Manish: http://stackoverflow.com/questions/427207/can-git-hook-scripts-be-managed-along-with-the-repository
  • jack: Might help, even if the hook was only on push to detect force and check to make sure you confirm it...
  • kmc: That's the point of -f in the first place! --force=50kN?
  • jack: Well, people know it's force, but also double... And when it's done, it's over.
  • kmc: Yeah, you can't fix things once you break it.
  • zwarich: I've also found that even if I follow the rules, sometimes the review will end up in an unreviewable / unfinishable state. No idea what causes it. It's really frustrating when that happens.
  • jack: When I've had problems on a single patch, jgraham and people upstream can help. Maybe we need to raise these issues with the critic team?
  • mbrubeck: Main issue is sometimes there are just bugs in critic that we can get fixes. But the other is that Critic itself is kind of a hurdle for new contributors. They don't know how to work with it; don't hang out in IRC all day to ask.. especially for small patches, maybe we should just do the reviews on github.
  • kmc: Yeah, it was originally optional, but it seems that Critic has become more mandatory. Maybe have Critic not pull in small patches? Critic is better for the big stuff...
  • SimonSapin: Two workflows is kinda rough.
  • kmc: People already discuss on github anyway. Not totally agreeing with myself, but does seem like we should solve it.
  • manish: We could just use github for new contributors, and introduce Critic once they're used to it. Most of the long-term contributors use Critic already; mainly just new people.
  • zwarich: Sort of tautological: if you were a person who hated critic, you already left...
  • jack: Don't know how many we've lost because of Critic.
  • zwarich: We don't have a questionnaire for why the people who've submitted a couple of patches and left did so.
  • jack: Problem is that Github's workflow has improved, but a force-push still requires re-review.
  • kmc: Reviewing a rebase is essential, though it doesn't work that well...
  • ms2ger: You can fix force-push with critic by force-pushing the exact ref it was in the reflog, reenabling tracking.
  • kmc: Maybe we could document that better.
  • jack: Have to teach people to use reflog who haven't done so before...
  • kmc: That's an essential git skill. They should learn it.

more items?

  • azita: Did you sign up for dinners at portland? Use the spreadsheet and put your names on if you haven't!
  • jack: I suggest finding people you want to eat with, if you can't find your top restaurant choices. Need to infiltrate dinner parties.
  • larsberg: I've been suggesting to people on other teams that they should get a Q1 goal around Servo!
  • jack: Maybe we need E-MozGoals that are perfectly sized for a one-quarter task for an experienced gecko developer.
Clone this wiki locally