On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo <span dir="ltr">&lt;<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>2) Possibility of the sheriff getting it wrong.</div><div><br></div><div>(2) concerns me most.  We&#39;re talking about using filenames to serve as a kind of unchecked comment.  We already know that comments are usually bad because there is no protection against them going stale.</div>
</div></div></blockquote><div><br></div><div>I don&#39;t see how this is parallel to stale comments.  Tests get continually compared to the given output and we see immediately when something changes.</div><div><br></div><div>
It is certainly possible for whoever assigns the filenames to get things wrong.  There are basically two mitigations of this.  One is allowing the existing &quot;expected.xxx&quot; file extensions to remain, and encouraging people to leave them as-is when they&#39;re not sure whether the existing result is correct.  The other is for sheriffs to use this signal as just that -- a signal -- just as today we use the &quot;expected.xxx&quot; files as a signal of what the correct output might be.  The difference is that this can generally be considered a stronger signal.  Historically, there&#39;s been no real attempt to guarantee that an &quot;expected&quot; result is anything other than the test&#39;s current behavior.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">I&#39;m sure some would love to get rid of Skipped files just as much as I would love to get rid of TestExpectations files.  Both are valid things to love, and imply that there must surely exist a middle ground: a way of doing things that is strictly better than the sum of the two.<br>
</div></div></blockquote><div><br></div><div>That&#39;s exactly what we&#39;re trying to do.</div><div><br></div><div>The value of this change is that hopefully it would dramatically reduce the amount of content in these, especially in TestExpectations files.  If you want to kill these so much, then this is a change you should at least let us test!</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"></div><div>In particular, to further clarify my position, if someone were to argue that Dirk&#39;s proposal would be a wholesale replacement for TestExpectations, then I would be more likely to be on board, since I very much like the idea of reducing the number of ways of doing things.  Maybe that&#39;s a good way to reach compromise.<br>
</div></div></blockquote><div><br></div><div>It&#39;s hard to know if we could completely eliminate them without testing this, but yes, one goal here is to greatly reduce the need for TestExpectations lines.  A related goal is to make the patterns and mechanisms used by all ports more similar.  As someone who has noted his frustration with both &quot;different ways of doing things&quot; and &quot;philosophical directions chosen by one port&quot;, you would hopefully be well-served by this direction.</div>
<div><br></div><div>PK</div></div></div>