On Thu, Aug 25, 2016 at 1:55 PM, Manish Goregaokar <man...@mozilla.com> wrote: > > There are a lot of issues with this.
I agree that there are challenges with mirroring the root Servo repository into m-c, but I'd like to make sure we mention some of the positives that we get from it: - Having "servo" in-tree means that Gecko developers will be actively contributing to both Gecko and Servo itself. This is a huge win for Servo. We're a small team, and even though we have a great volunteer community, Gecko is a source of deep area experts that are really difficult to find or grow elsewhere. Doing things that make it easier for them to contribute is really going to benefit the project. - I want to see parallel layout in Gecko. And I want to see Gecko developers helping us gut, replace, and share other components (media, net, etc.) that make both browser engines better. Mirroring Servo in-tree is the best way to do that for components that - like style - are deeply integrated in the browser engine and cannot meaningfully be "split out" into a repository with stable APIs. > 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. I would only expect this to increase cycle times for PRs to Servo that touch the geckolib bits - otherwise, we will just be running the good 'ole Servo infrastructure pieces, with just our known cycle times and intermittent woes. After some brainstorming, one idea that came up is that we could leave the tests in the servo repository, but in the mirrored copy in m-c, we will not copy in the tests. They'd still be run in Servo's automation, and there's an interesting edge case where m-c developers who add a feature to style that makes a new test pass may need to update the servo test manifest but can't see the test in-tree, but that doesn't seem like a huge problem. Developers coming from the servo/servo side would still be able to add new tests in the normal way. And let's be clear upfront about backouts - the expectation is that there will be *no* backouts affecting the branch in which servo would be mirrored (servo-inbound) except in the case where two commits to servo-inbound had no merge conflict but had a semantic conflict and were not tested against a common master. If we end up in a state with frequent tree closures or backouts, things have gone horribly wrong, and Steps Will Be Taken. We've made a lot of effort to have pretty solid CI on the Servo side, and 100% of the people I talk to in similar positions on the Firefox side want to be in a similar place themselves and support us on our way there. > 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. > 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. So, I think the downsides here are much worse than stated. After talking with Bobby (and seeing Emilio's mail) these are *not* changes that merely require a pair of hands to update Servo to the changes. The style system is not a natural module boundary with a stable interface - many code and data representation optimizations need to be deeply integrated between the two engines, and it sounds like often only the person doing that change will have the background necessary to do both. And I think that having a "you should also have a Servo PR open" ideal is not going to fly. You might as well rename Servo to ThunderServo :-) Even if everybody comes into this with the best intentions, we do not have the tooling, process, or culture to support that kind of workflow on a highly unstable module like that. > 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. tbh, I probably shouldn't ever have used the word frankenbuild, as it makes everything seem a bit more monstrous and scary than it needs to be :-) We're not proposing using two different build systems stitched together. It's all cargo, all the time. - Lars _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
