<br><div class="gmail_quote">On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke <span dir="ltr"><<a href="mailto:dpranke@chromium.org" target="_blank">dpranke@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We don't currently support port-specific reftests (or at least, not<br>
very well), and we certainly should be trying to minimize where they<br>
occur.</blockquote><div><br></div><div>Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working.</div>
<div><br></div><div>[1] <a href="http://trac.webkit.org/changeset/133529">http://trac.webkit.org/changeset/133529</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At any rate, we encourage people these days to check in expected<br>
failures rather than suppressing them using the TestExpectations<br>
files.</blockquote><div><br></div><div>The problem is essentially a chicken and egg problem. I don't know what the per-port failures will be ahead of time, but I do know the set of "correct" expectations. Since I am (independently) unable to build/test all ports run by build bots, I would like to commit the set of tests plus known good expectations as a preliminary step (with a generic skip all tests for all ports), and then subsequently commit the feature itself, and then subsequently override the generic skip on a port specific basis, effectively re-enabling the tests on a port by port basis as I refine the feature patch (as needed) to handle port specific behavioral differences.</div>
<div><br></div></div>