On 22/06/16 14:27, Boris Zbarsky wrote:
1) One side (the wpt side) has pretty trivial integration tests: it
basically just tests filename length. So if Gecko-side changes break
those tests fixing is not too terrible.
2) The other side (the gecko side) has a way to annotate failing
things, and whatever starts failing after a change on the wpt side is
just annotated as failing and checked in that way. I think this is
pretty broken, but that's what we're doing right now...
Needless to say, something like the style system would have somewhat
different constraints on whether it actually needs to pass tests (for
real, not for purposes of the test harness; just annotating stuff as
"known fail" and moving on is not really what I anyone is looking for
here). But even with the behavior above wpt merges are a huge
time-sink. Just talk to jgraham.
Yeah. I'm not really sure how we would do better than annotating
expected results with wpt merges, although we can for-sure do better at
making the failures we are importing more visible. But the way the sync
works is clearly not optimal; downstreaming in batches is probably
necessary to allow the expectation data to be merged, but we should
switch to a system where upstreaming happens when the patch lands on
m-i, to reduce the chance of merge conflicts (at the moment I have to
solve these manually, and fixing conflicts in code you have never seen
before is not ideal). Of course making this change would lead to the
possibility of backouts, which probably shouldn't be reflected upstream.
Anyway, that was somewhat off-topic, but insofar as I had a point
related to the original discussion it was "merge little and often, and
do everything you can to avoid merge conflicts, because they will make
you sad".
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
