> 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.
The other proposal includes making sure Gecko related stylo changes don't break Servo, but this does not. It seems easy enough to add Servo's test suite to the m-c side CI, so I would propose to add that to your proposal. That means we only have to resolve conflicts until CI is fully baked instead of forever. > 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). We're used to this so this doesn't bother me as much. I'd like to hear from people hacking on layout whether they think this would be an impediment. > 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. Bobby's claim was that almost all changes are breaking ones. If that's true, I don't see how we're going to avoid people needing to fix up the Gecko side. But at least with your proposal that more explicitly limited to the style system. While in theory that shouldn't make a difference, I think this will make it easier to deal with problems like intermittents. For example, there's no way a change to servo/servo itself could trigger intermittents on the Gecko side. > 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. WR is easier to separate (or at least it appears so) than style, so this is probably the next longest pole in the tent. I agree that it's farther enough down the line that we are likely to have more experience and knowledge about the problems which may allow for better solutions to emerge. > 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. This is probably the messiest bit, as updating any dep of style may require changes on the Gecko side. That dependency graph is pretty small at the moment, so perhaps this issue isn't a huge one. > What do you think? It certainly seems much simpler. jack. _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
