<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 15, 2012, at 5:51 PM, Peter Kasting &lt;<a href="mailto:pkasting@chromium.org">pkasting@chromium.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Wed, Aug 15, 2012 at 5:45 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">The typical approach used in situations that you describe is to rebase, not skip.</div></blockquote><div><br></div><div>Which is precisely what Dirk is proposing. &nbsp;Literally the only difference here is that the rebased test expectation would contain an optional notation about whether we believe the new baseline to be correct or incorrect.</div></div></div></blockquote><div><br></div><div>Can you articulate the value that this gives? &nbsp;We must weigh that against the downsides:</div><div><br></div><div>1) Increased complexity of infrastructure.</div><div><br></div><div>2) Possibility of the sheriff getting it wrong.</div><div><br></div><div>(2) concerns me most. &nbsp;We're talking about using filenames to serve as a kind of unchecked comment. &nbsp;We already know that comments are usually bad because there is no protection against them going stale.</div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Ports that don't care, or tests where we don't know, will be totally unaffected. &nbsp;I am not sure why this bothers you so much. &nbsp;You talk about making the infrastructure more complicated, but it doesn't seem like there is much additional complication involved, and what minor complication is involved is being volunteered to be handled by Dirk and other folks.</div></div></div></blockquote><div><br></div><div>Ultimately it will lead to a further multiplication of number of possible ways of doing things, which is bad. &nbsp;I'm sure some would love to get rid of Skipped files just as much as I would love to get rid of TestExpectations files. &nbsp;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.</div><div><br></div><div>In particular, to further clarify my position, if someone were to argue that Dirk'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. &nbsp;Maybe that's a good way to reach compromise.</div><div><br></div><div>Dirk, what value do you see in TestExpectations were your change to be landed? &nbsp;Do scenarios still exist where there would be a test for which (a) there is no -fail.* file, (b) the test is not skipped, and (c) it's marked with some annotation in TestExpectations? &nbsp;I'm most interested in the question of such scenarios exist, since in my experience, whenever a test is not rebased, is not skipped, and is marked as failing in TestExpectations, it ends up just causing gardening overhead later.</div><div><br></div><div>-F</div><div><br></div></div></body></html>