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 as a result of changes in the "other"
repo.
I personally prefer having to do a controlled tough sync every now and then
over the lockstep thing.
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
this substantively different? I realize it's different in a practical
sense because the costs are higher than normal per-commit testing, of
course.
Also, we can alleviate part of this by doing syncs smartly. Just because
you *can* make a change without touching Gecko CI doesn't mean you should
:) If the reviewer thinks that a change to Servo style is expected to
affect Gecko, a gecko-try run should be made too with a sync applied (this
automation is easy enough to write). Once it merges, perform a sync if you
feel it necessary. This lets changes like refactorings, dependency updates,
etc become less of a pain
You make it sound like refactorings don't introduce bugs. ;)
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
