forked from servo/servo
-
Notifications
You must be signed in to change notification settings - Fork 0
Meeting 2015 09 21
Josh Matthews edited this page Sep 21, 2015
·
1 revision
Vidyo links:
- *** Early meeting: https://v.mozilla.com/flex.html?roomdirect.html&key=aiRAKuP7pjdJ (Servo)
- Late meeting: https://v.mozilla.com/flex.html?roomdirect.html&key=hn5vMQLsWV19 (ServoSamsung)
Reminder: use http://benjamin.smedbergs.us/weekly-updates.fcgi/
- layout meeting debrief (simon, pcwalton, mbrubeck)
- Should we be reviewing submodule updates as we pull them in? (larsberg)
- Exposed bugs (jdm)
- Use https://github.com/servo/skia-snapshots ? It’s 11 MiB to clone, vs 330 MiB for servo/skia (simonsapin)
- Master branch is now "protected" from accidental push (larsberg)
- brson, jack, pcwalton, manishearth, larsberg, simonsapin, jdm, edunham, mbrubeck, martin, ms2ger
- mbrubeck: We made plans for Fragmentation, pixel snapping.
- pcwalton: WebRast is coming!
- mbrubeck: gw has some awesome initial results and new demos to show them off.
- larsberg: We often rubber-stamp PRs for updating external dependencies. It's been fine so far, but I'm curious what we want to do longer-term.
- mbrubeck: I try to scan the changes in the upstream repo. Kinda trusting upstream maintainers' master branches.
- jdm: Depends on the repository. Some have thorough reviews - don't mind random upgrades to hyper. But other ones?
- brson: How do we check license compatibility?
- larsberg: I scan them manually. There's an open issue to create a tidy.py extension to help with this. We've caught some issues already with GPL or LGPL code that we had to try to get reliscensed.
- jack: Next time we pull in new dependencies (including when we update to a new version of an existing crate that pulls in new downstream dependencies)... maybe we could get high-five to notify when new dependencies are added and need to be audited. I'm not sure we need to worry about dependencies of dependencies if we trust upstream maintainers to get it right...
- mbrubeck: I don't necessarily trust upstream devs to get licensing compatibility right if they don't have dedicated legal counsel.
- jack: Also for some new dependencies we end up with big blocks of code that don't get many eyes (like gaol, for example).
- pcwalton: For stuff like that I'm happy to do in-person reviews and walkthroughs since it's a lot of platform-specific stuff.
- jack: Being notified that stuff is added is a good first step. What about mozilla-central? It's in-tree, so I guess you can only link to system libraries or vendor stuff. Want a check that Cargo.lock that is built with is same that was present before. Could check that file at end of build is same as first.
- mbrubeck: Also makes people's working dirs dirty, so easy to notice.
- jack: Problem when forgetting to update gonk/cef lockfiles, since it can end up pulling in a more recent version that is released without any notice. This has happened a few times. I'm less worried about the one we all use for main development.
- jdm: Maybe renaming the issue tags to be more reflective? Also, samfoo wrote a webpage that grabs issues from our tracker & can expose them in a nicer way. Removes ones marked as assigned, and highlights assigned ones that have not seen activity for several weeks. It's a new repo in our org: https://github.com/servo/servo-starters
- jdm: Current prototype is at: http://www.ifdown.net/servo-starters/
- jdm: Look at it & file issues!
- mbrubeck: I want to pull in issues from all of our repos.
- jack: Awesome! On tag renames, I agree with many of points. I'll comment further later. Where is it stored?
- jdm: It's a static webpage. If we want to use a GH account to avoid running out of API limits, can do as a Heroku app or something else that stores our secrets.
- jack: I'd sorta like this on servo.org.
- mbrubeck: Also see if other projects want to use it? e.g., Rust?
- brson: I'm intrigued and want it for Rust! Keep them separate, or share?
- jdm: Competition for bugs ahoy...
- jack: Seems like should just be able to list all the repos and tag names in config files, run from the same codebase but potentially separate.
- brson: Rust is creating another web app on Github around feature progression, the RFC process, etc. to report status. Basically a GH scraper. Don't know if it's relevant, but lots of this stuff is going on.
- jack: Seems like a simple template that manages github APIs and secrets etc. could be valuable, so we could all work from a common base. Who's doing the Rust one right now?
- brson: Maybe steveklabnik's partner?
- jack: I'll reach out to her and samfoo and see what we can do here.
- brson: Perhaps include rust-community?
- jack: We need to do something. It's the biggest complaint of new users. At least half a dozen bug reports of "broken build" because it takes so long. What's the easiest way? Blowing away a the skia repo?
- SimonSapin: If we do this, every time we make changes to or update skia from upstream, we have to run a script to update the repository. Not as convenient to perform skia updates as it is now.
- jack: What's the full proposal? Even if we just squash the history and just land updates it'd be good.
- SimonSapin: Yes. One repo with all of the history in case we want to
git blameand the other one with just one commit. - mrobinson: Can Cargo shallow clone?
- simonsapin: There's an issue, but it depends on libgit2, which seems to be unable to add support.
- manish: Yes, it can't add shallow clones without breaking other users of the library.
- simonsapin: The problem is that skia compresses to 11MB, but crates.io only supports 10MB.
- jack: Doesn't crates.io only store the cargo.toml? Can't we just tell acritchto to increase the limit? Or whitelist some owners to have a higher limit?
- simonsapin: they suggest breaking up skia.
- jack: no way.
- mrobinson: Maybe move the custom code out (to rust-azure?) and then not update skia very often? I think we've pulled out the C++ stuff?
- mbrubeck: Similar questions updating harfbuzz and packaging icu. ICU is not in git. harfbuzz is in git, but wanted to use their tarball, both so it's easy to map to a release and the tarball has the
make distrun on it so you don't have to rerun autotools stuff. Any opinions on that? Unpacking the release tarball into our repo, instead of closing the upstream? - jack: For C libraries, that seems like exactly what we want to do. Fontconfig is a good example - we only use the release tags against their git repo. If the repo was large, we'd want to flatten. Might as well use tarballs checked into git repos anyway. We're not getting any value from having the history in the Servo tree. Skia's a hard case because we do modify it, though we're pretty much done with that now. Flat history would be a huge win for the initial developer experience for Servo. Let's just make sure it's not super annoying. The update would be fine; just keeping it going is annoying. Skia mainly gets build fixes, which are on our side. So lots of hassle to update skia.
- simonsapin: Just running a script & pushing to a repo.
- jack: Can you file a bug about the crates.io size limit? Then we can discuss it.
- simonsapin: If that happens, we don't need snapshots of skia. Can just put it on crates.io and be done.
- larsberg: I've disabled the ability of anybody to push to master. Need to go into settings as owner and disable that option in order to revert that protection. This doesn't prevent accidentally pushing mergeable changes over, just protects against rewriting history. We could also prevent merging any branch into master that doesn't pass github status checks. Might try that out on a dependency on first, but for stuff where we have homu automerging after running travis checks, that could prevent accidentally pressing the big green merge button.
- jack: Anybody adding new stuff to homu, the scripts that I posted are broken for 2FA. I can update them to take a new parameter for the OTP token. Lars, I think your script you used to gather accounts missing 2FA missed some people, since bors wasn't nagged.
- larsberg: Only nagged owners, so I made bors no longer an owner.
- jack: With bors not having 2FA, it has a long randomly-generated passwords. Not prey to lists of popular passwords.
- edunham: Where's the password live?
- jack: I have it, and jdm might have it from a GPG email long ago.
- larsberg: Not in the pillar?
- jack: I don't think so.
- manishearth: Isn't there an etherpad for research managers?
- larsberg: No, that has build machine passwords.
- edunham: If jack's computer spontaneously combusts, we've lost access?
- jack: jdm has it!