My main issue is that backouts aren't addressed. They are reasonably common in m-c (admittedly, this was a few years ago; I haven't been watching Firefox dev lately) due to the model where tests run after merges. On the other hand, Servo's model never has backouts, and isn't well equipped to deal with them. Ignoring backouts makes the model much simpler, much like a Penrose tribar without the third edge :)
Servo is used to making atomic changes, getting a quick-ish merge to master, and iterating off that. We often are blocked on someone else's PR landing, for example (perhaps due to the smaller team?). I suspect that our code has organically grown to make this easier, and as Lars mentioned last week, this has made the team care about CI cycle times a lot more. I was chatting with mystor about this last week, and it seems like Gecko is more used to the push-and-forget model, where you don't care about a patch once it is in inbound. This means that if the tree gets closed due to bustage/backouts, it's fine, even in a world without inbound. Most solutions for backouts will involve tree closing for Servo too, which breaks this workflow. Something has to give; I suspect we'll just have to learn to use `try` more and follow a similar r+-and-forget model :) An alternate solution is to just publish style as a crate. Bobby broke off a lot of the servo-specific dependencies when doing the geckolib stuff, now style just depends on util (and plugins for linting). We can publish style/util (the geckolib version) and ignore plugins (they're not safety-necessary for style). This makes it harder to contribute to servo style, but it makes it easier to bump Servo's dependencies without having to make a corresponding commit to m-c. Style depends on a lot of crates.io dependencies -- in the proposed system if one is bumped in Servo it will have to be bumped in m-c too. Playing around with git log <https://manishearth.pastebin.mozilla.org/8878551> (unscientifically) shows me that most commits to style touch other crates too, mostly script and then layout -- so it might be best to not split style out. Thanks, -Manish Goregaokar On Mon, Jun 20, 2016 at 8:31 PM, Lars Bergstrom <larsb...@mozilla.com> wrote: > As many of you may have seen from the document > ( > https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU/edit > ) > and discussions on dev-build and at the workweek, we have an > increasing desire to be able to try to develop and potentially ship > Servo code in Firefox. While this is exciting (yay, customers! yay, > faster Firefox!), it also means that we're going to be subject to some > growing pains as we around the requirements of our largest and best > customer. > > We'd like to hear your comments here (or privately, if you prefer) > about these proposed changes. We're trying to figure out all of the > details, so now is the right time to bring up objections or > requirements! > > 1) Move our CI testing for servo/servo off of buildbot and into releng. > > In order to ensure Servo changes do not break Firefox and vice-versa, > we are proposing unifying our autolanders and moving Servo's tests (as > Tier 1 - must pass to commit!) into releng. This would also mean > running relevant Firefox tests against Servo. > > 2) Move webrender and webrender_traits back into the Servo repository. > > Because WebRender and Stylo are the two biggest projects that will > need to be worked on in a cross-cutting way across Firefox and Servo, > we'd like to have them out of a separate GitHub repo (with its "update > version, PR, cargo publish, pull down, repeat" workflow) and in the > one that is being tested and co-landed with Firefox. We plan to push > webrender to crates.io to ensure it is still separately usable by > other projects. > > 3) Get Stylo and WebRender onto stable Rust. > > It is the intention to ship Rust code in Firefox using only stable > Rust features. That's not a hard requirement, but it means trying to > either stabilize features or rip out any unstable/nightly-only > features in use in either the Stylo or WebRender dependency graphs. > > Please provide feedback on these topics or any others that come to > mind around these changes! Many of us across the company will be > working hard in the coming weeks to get a concrete proposal and > timelines in place for this work, so please reach out with your > concerns ASAP. > > Thanks! > - Lars > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
