On discussing this in IRC, it occurs to me that my alternate solution was poorly worded. The idea is not *necessarily* to publish style as a crate.
As I understand it, crates like webrender/rust-url which Gecko would like to directly use (but are not part of components/) will be vendored in tree, with a wpt-like two-way sync, instead of lockstep evolution using autolanders. Changes to webrender would be made in m-c or servo/webrender, whichever is more convenient, and there is a periodic sync operation. What I wish to do is to use this solution for style. If style stops depending on servo-specific things (right now it depends on util, but we can split those things out), then this same solution becomes viable for it. It is not necessary to put style in a different repo or publish it as a crate, though I am receptive to that idea too (others may not be). This solution lets us use existing tooling (or, tooling that is going to exist anyway, due to WR and rust-url) and existing practices without having to tie our CI times to m-c's. As Ms2ger says below, we are very susceptible to the effects of slow CI. I think perhaps it might help to get some clarity on exactly which changes will trigger a m-c CI build in Servo. Do lockfile changes cause this build? What about edits to util? Thanks, -Manish Goregaokar On Tue, Jun 21, 2016 at 4:16 PM, Manish Goregaokar <manishsm...@gmail.com> wrote: > 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
