Hi, The current situation with the m-c vendoring for stylo is to put all of stylo in-tree and have an autolander dance between homu (or at least Servo buildbot) and the Gecko autolander that ensures that changes to servo/servo or m-c are always mirrored and fully tested, on both ends.
There are a lot of issues with this. It increases cycle times for Servo PRs. We'd need to move wpt out of tree, which discourages people from writing tests (see the thread about tests/). Backouts on m-c tip may cause worse problems. An alternate solution is to break style/, tests/unit/style, and style_traits/ (and perhaps util/) into a separate git repo, used in servo as a git dep (We could publish on crates.io, but I don't think we need to). It gets vendored into m-c using the same plan as servo; using autolander voodoo to keep github.com/servo/style and m-c/some-dir/style up to date. The downsides get limited to style, and the tests/ issue goes away. The voodoo is also significantly less voodoo-y -- style has a smaller set of tests which could be run in-tree from m-c itself. (An alternate way of syncing is to use the wpt-like manually-initiated two-way sync for style, which would further improve cycle times, but would shift the collective burden to the person doing the sync. I'm open to this too.) The downsides of this model are: - Servo has to periodically sync with style and resolve conflicts. I volunteer as tribute to do these. I suspect they won't be too bad, and once stylo settles down a bit there won't be many breaking changes. - Landing simultaneous changes to style/ and layout/ becomes harder. We have path deps to simplify working on these, and landing them is two-step now, something we're already used to for other crates (and it's easier for style because it will be a git dep, not crates.io). There is the issue of changes to style and layout that change style's public API or otherwise break m-c. I'd like to avoid forcing style contributors to have an m-c clone handy to work on these. A simple solution is to temporarily fork into a branch on the style repo, and have it dealt with in the next sync. While this is pretty bad it's not much worse than the situation for contributing to style in the frankenbuild world anyway. - We may need to frankenbuild anyway for layout if gecko ever wants to use that. Though afaict that's in the far future if it ever happens, and the solution space will probably have changed by then. Layout could probably be split out if necessary (the layout logic, not the RPC/IPC glue), since it mainly only talks to style. - Style can no longer pin to deps -- it's possible that Servo's lockfile and Gecko's vendoring diverge. As long as semver gets followed in the deps, this won't be an issue. This is probably not going to be the case, but it shouldn't be something which we can't handle. I personally feel that the downsides aren't that bad, compared to the frankenbuild. It also isolates the downsides to one crate, a crate which would anyway be tricky to work with in the frankenbuild world. What do you think? Thanks, -Manish _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
