On Tue, Dec 22, 2015 at 1:59 PM, Ryan VanderMeulen < rvandermeu...@mozilla.com> wrote:
> Can you provide some context to this discussion for those of us who know > little to nothing about the work you're discussing? > This is a fork of the thread in https://groups.google.com/forum/#!topic/mozilla.dev.servo/qESJoCIsPU8 . > We're going to start sharing a common style system between Servo and Gecko? > Maybe. We are exploring the feasibility and benefits of doing so on the code-side. While we do that, we're also discussing what the sharing might look like. > When? :) > Still very much in the exploratory phase. I would hope that we'd have a clear-ish sense of whether we're going ahead with this by London. -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
