Skip to content

Meeting 2015 11 09

Jump to bottom
Lars Bergstrom edited this page Nov 10, 2015 · 1 revision

Agenda items

Attending

Last week

Sub-project GitHub pages

  • jack: Do we want to remove issues and wikis on our sub-repos and just point to the servo/servo repo?
  • edunham: I'm in favor. One downside is you can't use just #1234 to link to an issue from a PR.
  • jack: What happens to PRs if we turn off issues?
  • edunham: I think PRs are unaffected.
  • jack: What's the motivation for turning off / consolidating issues?
  • mbrubeck: There's currently no good way to search issues across all our repos.
  • edunham: There actually is. https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+user%3Aservo+is%3Aissue
  • jack: You have to go to the org page.
  • jack: I guess one of the issues is people might not be watching all the subrepositories, and might not get notified.

Landing page

  • jack: Two different people submitted proposed servo.org web page designs. Now we need to pick one, or provide feedback or something. Any opinions?
  • edunham: The more colorful one is a bit more complete, but the visual design of the plainer one is more consistent with our other branding. The colorful one seems more playful, cutting-edge. The white background one seems more professional and polished. Depends what impression we want to give.
  • Manishearth:Our logo is a doge so professional is already out the window.
  • jack: Whatever we pick we can change it later.
  • bholley: The plain one looks more like a research project to me. The colorful one looks like we're trying to get people to give us money.
  • jack: Should we ask the two contributors to work together?
  • edunham: We should clarify our goals.
  • jack: I definitely prefer the typography on the plainer one, but the more complete content on the other one.
  • bholley: Servo will always be more developer-focused than user-focused. It's an engine, not a product.
  • jack: It depends. This is where people will go to get nightly builds once we have them.
  • bholley: Will "Servo" be the branding of the nightlies?
  • jack: For now Servo is the only name we have for the project.
  • edunham: Should we try to take some of the content/icons/links from the more colorful page and integrate them into the design of the plainer page?
  • jack: Okay. edunham, can you pass that feedback along?
  • edunham: Okay. (done: https://github.com/servo/servo/issues/8365#issuecomment-155241242)

Workflow

  • bholley: I don't have a detailed proposal here. Based on my experience with rust-selectors... It's a tedious process when you have a change that spans two repos. You need to manage the two branches together and refer to the correct version rev from the other repo. It gets even more annoying if you want to rewrite history to get a clean set of micro-commits. Maybe it could be solved with tooling changes. Like a git plugin that could link together commits across repos as you rebase.
  • Manishearth: Are you using path overrides?
  • bholley: Yes, but the issue comes when I want to push something. Each commit should be logical and self-contained, and it's annoying to have each commit in a Servo branch reference the right commit in a rust-selectors branch.
  • brson: Do we have a picture of what the ideal workflow looks like?
  • bholley: The specific thing i'm imagining is, say I've got a series of like five commits. And commits 2 and 5 also depend on changes in rust-selectors. So the base commit needs to be at the current rust-selectors, and commit 2 needs to bump the rust-selectors rev...
  • Manishearth: I think the workflow we use for that is to use a path override, work on it locally without touching the version at all, finish making the changes, and do a single version bump at the end.
  • brson: That obviously breaks history, right? There are a bunch of intermediate commits that don't actually build.
  • bholley: Right, and it means you can't go back and bisect for regressions, e.g.
  • Manishearth: You could make rust-selectors a git dep instead of a crates.io dep, and have a diff
  • jack: But in general we prefer crates.io dependencies, especially for libraries that other people are using, and it doesn't work well to have mixed git and crates dependencies.
  • mbrubeck: In some ways crates.io dependencies are easier because the version numbers don't change when you rewrite your history.
  • bholley: But they do if you rebase on someone else's changes that land before yours.
  • jack: And you have to publish each intermediate version.
  • brson: Linux distros packaging rust software want to provide dependencies themselves rather than have Cargo download them. Gecko devs want to vendor all dependencies into mozilla-central. larsberg brought up that if we had Cargo tooling that worked in both directions (import/vender something into the tree, and also export in-tree packages, then it could help with Servo's repos.
  • bholley: Monorepos are really nice when you're changing a lot of things.
  • mbrubeck: Maybe it makes sense to have rust-selectors in tree like most of our core crates currently are?
  • jack: I'll bring this up to larsberg so he can talk about it with the Cargo team. And if anyone has tooling ideas, let us know.

Rust blockers

  • jack: larsberg recently refreshed https://github.com/servo/servo/issues/2853 which is our list of Rust/Cargo bugs that are important to us. Take a look and make sure any of your pet issues are filed and listed there. bholley, you might want to file something for the workflow discussion above.

Homu try issues

  • Manishearth: https://github.com/servo/servo/pull/8341#issuecomment-154606844 (@bors-servo: retry try- r+)
  • Manishearth: If there's a regular build failure followed by a try build failure, and you want to do a regular build again, you need to remove the try flag first. I'm trying to fix this. The solution in the comment above should work in almost all situations for now.
Clone this wiki locally