Can you provide some context to this discussion for those of us who know little to nothing about the work you're discussing? We're going to start sharing a common style system between Servo and Gecko? When? :)
-Ryan On Tue, Dec 22, 2015 at 4:23 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > 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
