> The other proposal includes making sure Gecko related stylo changes > don't break Servo, but this does not. It seems easy enough to add > Servo's test suite to the m-c side CI, so I would propose to add that > to your proposal. That means we only have to resolve conflicts until > CI is fully baked instead of forever. > > This brings up the issue that changes to m-c's vendor may require changes to servo/servo, which has the same set of problems, bringing us back to square 1 where we just vendor all the things.
Not gating on Servo's CI means that we can just handle it during the sync. (Optional non-gated CI sounds nice to have though) Bobby's claim was that almost all changes are breaking ones. If that's > true, I don't see how we're going to avoid people needing to fix up > the Gecko side. But at least with your proposal that more explicitly > limited to the style system. While in theory that shouldn't make a > difference, I think this will make it easier to deal with problems > like intermittents. For example, there's no way a change to > servo/servo itself could trigger intermittents on the Gecko side. > > Temp-branching until a weekly sync is a solution here. Such a solution isn't available in frankenbuild at all -- style-api-breaking-changes must be coordinated across repos. Though I guess part of this depends on where ports/geckolib will live -- in m-c only, or in the style repo (which itself is vendored in m-c)? If it lives in the style repo, I don't think we'll have many breaking changes since you can fixup geckolib when making PRs to style. Workflow for working on stylo is unchanged since everything is vendored anyway. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
