Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

Coordinating rollups across two repos will be a pain. The proposed automation sounds better to me. -Manish Goregaokar On Thu, Jun 23, 2016 at 10:08 AM, Michael Howell wrote: > If the model you're proposing is "almost isomorphic" to roll ups, then why > not just use

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

I just chatted with Manish a little bit to sort out some details and misunderstandings, and I think we're much more on the same page now. A few high-level points worth emphasizing: * Making the Homu queue take longer would be bad and we should avoid that. I believe the proposal would actually

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On 6/22/16 11:17 AM, Manish Goregaokar wrote: We don't close down the tree except for CI fires Yes, I understand your model. You don't have to explain it to me. I was just pointing out that for normal commits you prefer the model of test-each-thing, but for style system you would prefer the

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On Wed, Jun 22, 2016 at 5:17 PM, Manish Goregaokar wrote: > On Wed, Jun 22, 2016 at 7:38 PM, Boris Zbarsky wrote: > > > As a matter of dealing with test breakage and how it's resolved, do you > > also prefer doing a bunch of commits and only then running

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On Wed, Jun 22, 2016 at 7:38 PM, Boris Zbarsky wrote: > As a matter of dealing with test breakage and how it's resolved, do you > also prefer doing a bunch of commits and only then running tests, and if > they fail closing down the tree until it's all resolved? If not, how is

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On 6/22/16 9:52 AM, Manish Goregaokar wrote: This has one significant drawback: it places a pretty serious burden on whoever performs the sync. In particular, in addition to merging the actual code (already needs some expertise), they become responsible for handling any test failures that arise

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

> This has one significant drawback: it places a pretty serious burden on > whoever performs the sync. In particular, in addition to merging the > actual code (already needs some expertise), they become responsible for > handling any test failures that arise as a result of changes in the "other"

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On 6/22/16 8:47 AM, Manish Goregaokar wrote: Changes to webrender would be made in m-c or servo/webrender, whichever is more convenient, and there is a periodic sync operation. This has one significant drawback: it places a pretty serious burden on whoever performs the sync. In particular,

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

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

Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox

On 20/06/16 17:01, Lars Bergstrom wrote: > https://docs.google.com/document/d/1uubYE7JXaVY10PoAY9BVx8A-T11ZxP1RYqNOrFJwdcU This document proposes, for code in servo/servo that is shared with Gecko: > 1) The code in servo/servo is all mirrored into a directory in > mozilla-central > > 2) When a