+1 to that. -expected.png / -failure.png is clearer than -expected.png / -previous.png or -expected.png / -correct.png.<div><br></div><div>It&#39;s hard to grasp the difference between &quot;expected&quot; and &quot;correct&quot; unless you fully knew how rebaselines worked in layout tests. Also, this model has a nice one-to-one mapping with entires in TestExpectations (with single expectation).</div>

<div><div><br><div class="gmail_quote">On Fri, Aug 17, 2012 at 8:02 PM, Filip Pizlo <span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

So this is down to expected/failing and expected/previous?<br>
<br>
I must say that expected/failing feels less confusing. Easier to remember if I have to quickly recall what it means.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Filip<br>
</font></span><div class="im HOEnZb"><br>
On Aug 17, 2012, at 7:36 PM, Dirk Pranke &lt;<a href="mailto:dpranke@chromium.org">dpranke@chromium.org</a>&gt; wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5">&gt; I&#39;m not sure if I like this idea or not. A couple of observations/questions ...<br>
&gt;<br>
&gt; 1) I wouldn&#39;t want to call it &#39;-correct&#39; unless we were sure it was<br>
&gt; correct; &#39;-previous&#39; is better in that regard<br>
&gt;<br>
&gt; 2) the issue with keeping a &#39;-correct&#39; in the tree is that it&#39;s quite<br>
&gt; possible for a previous correct expectation to need to change to a<br>
&gt; different expectation to still be correct. i.e., they get stale. I<br>
&gt; fear that this could quickly become more confusing than it&#39;s worth.<br>
&gt; It&#39;s also not clear to me when -previous gets updated or removed?<br>
&gt;<br>
&gt; 3) It also feels like &#39;-previous&#39; is something that we can just as<br>
&gt; easily get from SVN/Git/whatever, in a completely foolproof and<br>
&gt; automatic way. I grant that it&#39;s easier to just do a side by side<br>
&gt; compare, but &quot;diff against previous&quot; isn&#39;t that hard to do and we<br>
&gt; could easily write a wrapper to make it trivial ...<br>
&gt;<br>
&gt; 4) I&#39;d want to work through the various branches in the workflow more<br>
&gt; before I felt comfortable with this. When I was coming up with my<br>
&gt; original proposal I originally wanted to allow -passing and -expected<br>
&gt; to live side-by-side, but all sorts of complications arose, so I&#39;d be<br>
&gt; worried that we&#39;d have them here, too.<br>
&gt;<br>
&gt; -- Dirk<br>
&gt;<br>
&gt; On Fri, Aug 17, 2012 at 6:51 PM, Ojan Vafai &lt;<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>&gt; wrote:<br>
&gt;&gt; That matches my understanding. You proposed modification sounds fine to me.<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Aug 17, 2012 at 6:40 PM, Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; My understanding of the current proposal is this:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1) This applies to tests that fail deterministically, for reasons other<br>
&gt;&gt;&gt; than a crash or hang.<br>
&gt;&gt;&gt; 2) If the test has a new result that you&#39;re confident is a progression (or<br>
&gt;&gt;&gt; neither better or worse), you simply update the -expected.txt file.<br>
&gt;&gt;&gt; 3) If the test has a new result that you&#39;re confident is a regression, you<br>
&gt;&gt;&gt; delete the -expected.txt file and check in the new results as -failing.txt.<br>
&gt;&gt;&gt; 4) Ditto points 2 and 3 with respect to -expected.png, for image diffs.<br>
&gt;&gt;&gt; 5) We would stop using all other ways of marking tests that fail<br>
&gt;&gt;&gt; deterministically, including Skipped and the many things you could enter in<br>
&gt;&gt;&gt; TestExpectations.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is that correct?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If so, I&#39;d like to suggest a minor modification. In place of point 3<br>
&gt;&gt;&gt; above, I propose the following:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 3) If the test has a new result that you&#39;re confident is a regression, you<br>
&gt;&gt;&gt; rename the -expected.txt file to -previous.txt (or maybe -correct.txt or<br>
&gt;&gt;&gt; -pre-expected.txt or something) and check in the new results as<br>
&gt;&gt;&gt; -expected.txt (unless there is already a -previous.txt, in which case just<br>
&gt;&gt;&gt; update -expected and leave -previous).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I propose this for the following reasons:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; - It maintains the longstanding approach that -expected.txt reflects what<br>
&gt;&gt;&gt; is currently *expected* to happen, not whether it is right or wrong in some<br>
&gt;&gt;&gt; abstract sense. It is an expectation, not a reference.<br>
&gt;&gt;&gt; - It still leaves a clear indication of tests that somebody needs to look<br>
&gt;&gt;&gt; at further, to determine if a regression occurred.<br>
&gt;&gt;&gt; - It leaves both old and new result in place for easy comparison by an<br>
&gt;&gt;&gt; expert.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Regards,<br>
&gt;&gt;&gt; Maciej<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Aug 17, 2012, at 6:06 PM, Ojan Vafai &lt;<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; +1<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Fri, Aug 17, 2012 at 5:36 PM,<br clear="all">Ryosuke Niwa<br><font color="#999999">Software Engineer</font><div><font color="#999999">Google Inc.</font></div><div><font color="#999999"><br></font></div><br>


 &lt;<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; That&#39;s my expectation although we probably can&#39;t do that for flaky tests<br>
&gt;&gt;&gt;&gt; :(<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; e.g. sometimes fails with image diff.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Fri, Aug 17, 2012 at 5:35 PM, Filip Pizlo &lt;<a href="mailto:fpizlo@apple.com">fpizlo@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; +1, contingent upon the following: are we agreeing that all current uses<br>
&gt;&gt;&gt;&gt;&gt; of TEXT, IMAGE, and so forth in TestExpectations should be in the *very near<br>
&gt;&gt;&gt;&gt;&gt; term* following Dirk&#39;s change be turned into -failing files?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; -Filip<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Aug 17, 2012, at 5:01 PM, Ryosuke Niwa &lt;<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Fri, Aug 17, 2012 at 4:55 PM, Ojan Vafai &lt;<a href="mailto:ojan@chromium.org">ojan@chromium.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Asserting a test case is 100% correct is nearly impossible for a large<br>
&gt;&gt;&gt;&gt;&gt;&gt; percentage of tests. The main advantage it gives us is the ability to have<br>
&gt;&gt;&gt;&gt;&gt;&gt; -expected mean &quot;unsure&quot;.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Lets instead only add -failing (i.e. no -passing). Leaving -expected to<br>
&gt;&gt;&gt;&gt;&gt;&gt; mean roughly what it does today to Chromium folk (roughly, as best we can<br>
&gt;&gt;&gt;&gt;&gt;&gt; tell this test is passing). -failing means it&#39;s *probably* an incorrect<br>
&gt;&gt;&gt;&gt;&gt;&gt; result but needs an expert to look at it to either mark it correct (i.e.<br>
&gt;&gt;&gt;&gt;&gt;&gt; rename it to -expected) or figure out how the root cause of the bug.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; This actually matches exactly what Chromium gardeners do today, except<br>
&gt;&gt;&gt;&gt;&gt;&gt; instead of putting a line in TestExpectations/Skipped to look at later, they<br>
&gt;&gt;&gt;&gt;&gt;&gt; checkin the -failing file to look at later, which has all the advantages<br>
&gt;&gt;&gt;&gt;&gt;&gt; Dirk listed in the other thread.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I&#39;m much more comfortable with this proposal.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; - Ryosuke<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; webkit-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
&gt;&gt;&gt;&gt;&gt; <a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; webkit-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
&gt;&gt;&gt; <a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
&gt; _______________________________________________<br>
&gt; webkit-dev mailing list<br>
&gt; <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
&gt; <a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo/webkit-dev</a><br>
</div></div></blockquote></div><br></div></div>