Thinking about this a bit more, it occurs to me that style system changes that would require simultaneous Gecko fixup in the same commit are likely to also require simultaneous Servo fixup.
Given that, I think we probably want to vendor all of Servo, rather than just the crates we build in Gecko. This would facilitate making breaking API changes where we have consumers in both Gecko and Servo that need fixing up (fixing up multiple consumers alongside the API is one of the primary wins of mono-repos). This would increase the traffic of Servo->Gecko vendoring updates, but we would clearly tweak CI to no-op for those effectively-NPOTB changes. Long-term when we get partial checkouts, we could make the default checkout of m-c omit the Servo-only crates. On Tue, Dec 22, 2015 at 10:15 AM, Bobby Holley <bobbyhol...@gmail.com> wrote: > Here's a strawman proposal of what I'm imagining for the sharing of the > style system between Gecko and Servo. I'm sure there's lots wrong here and > stuff that can be tweaked, but I wanted to get a slightly more concrete > proposal out there for discussion. > > * In m-c, we have vendored directories for each Servo crate we use. > * For crates where we cannot come up with an identical peer list on the > Gecko and Servo side, the component is marked read-only except for upstream > updates (enforced with a push hook), and must be modified the slow way > (submitting patches upstream, and then pulling them in). > * For components with unified peers, we do the following: > ** Enforce the peer set with commit hooks on both the Gecko and Servo side. > ** Gecko and Servo try pushes which touch the shared code include an > additional job to run a try push on the other CI, and report the results. > If the peers enforce judicious use of try, this should catch most of the > cross-project breakage. > ** Each time a push which touches shared code lands in either repository, > a corresponding push (with non-squashed changesets) is prepared and > automatically pushed to the other repository. > ** If that push bounces, the repositories are marked as out-of-sync, and > an email is sent to the committer and the set of peers indicating that > manual fixup is required. > ** If possible, when the repositories are known to be out of sync, a > commit hook would prevent additional changesets from landing on either side > without a magic word in the commit message. > > Thoughts? > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
