<div class="gmail_quote">On Fri, Nov 4, 2011 at 7:03 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">On Fri, Nov 4, 2011 at 6:31 PM, Ojan Vafai <span dir="ltr"><<a href="mailto:ojan@chromium.org" target="_blank">ojan@chromium.org</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div><div class="im">On Fri, Nov 4, 2011 at 5:52 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:</div><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><span style="background-color:transparent">W3C's build step auto-generates them.</span></div></div></blockquote><div><br></div></div></div><div class="im"><div>I thought you were arguing that we should use manifest files for all reftests because having multiple ways to do things is confusing.</div>



</div></div></blockquote><div><br></div><div>I am, but I'm particularly concerned about W3C tests. It'll be nice if we had exactly one way of running / writing ref tests. I think we can easily automate the process of generating manifest files.</div>



<div><br></div><div>The work flow will be as follows:</div><div><ol><li>Write new ref tests using link element</li><li>Run some tool (maybe we can teach run-webkit-tests to do it automatically)</li><li>Upload patch with auto-regenerated manifest file</li>

</ol></div></div></blockquote><div>It's mainly step 2 that I have a problem with, although I also don't like that the test is not self-contained.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div><ol>

</ol></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div>But we don't need to structure them. They're organized in W3C's repo, and we're just going to import them in some directory; e.g. LayoutTests/w3c/. </div>

</div></blockquote><div><br></div></div><div>I'm reluctantly OK with doing this exclusively for test suites we import that come with a manifest file, since the maintenance cost is lower. Although, I'd prefer if we limited the number of ways you could mark a test as a reftest.</div>



</div></blockquote><div><br></div></div><div>Yeah, I won't be particularly happy about having two ways to write ref tests.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>If we're adding new tests that we intend to contribute back to W3C, then those tests should live outside of this directory. <span style="background-color:transparent">The preferred approach, however, is to add tests to W3C repo first, then import them back to WebKit.</span></div>





</div></blockquote><div><br></div></div><div>I don't think this is realistic. For example, for the new flexbox tests, we're writing them against WebKit's code and they're changing as we go. In addition, all the properties are webkit prefixed. We're not writing test suites in isolation. We're writing them as we implement the feature or fix the appropriate bugs.</div>



</div></blockquote><div><br></div></div><div>Right, but then you'll need to unprefix those tests and reformat them in order to upstream the tests anyway.</div></div></blockquote><div><br></div><div>Yes, but the point is that it doesn't work to right the tests in the W3C repo first because what goes in the W3C repo doesn't work for us until we unprefix our implementation.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div class="gmail_quote"><div><span style="background-color:transparent">I don't see what's special about reftests that we'd run them on a separate bot. We might decide to shard test running across different bots in some way, but sharding by test type seems unhelpful.</span></div>





</div></blockquote></div></div><div><br></div>I'm not talking about ref-tests. I'm talking about tests imported from the W3C test suite.</blockquote><div><br></div></div><div>Even then, I don't see any benefit to not running them as part of our main test suite.</div>





</div>
</blockquote></div></div><div><br></div><div>It all depends on the number of tests. CSS 2.1 test suite appear to contain 10,000+ tests (there are 10,000+ .xht files). If we're adding CSS3, and other test suites from W3C, it can easily be in the order of 100,000s given that W3C is trying to increase the number of tests significantly in the coming years.</div>



<div><br></div><div>Given we spend 10+ minutes running 26,000+ layout tests on our bots, adding 100,000+ tests will result in quadrupling our bot cycle time (to 40-50+ minutes; or to 3-4 hours for any bots that run pixel tests). It's definitely nice if we could run them all on the main waterfall with our regression tests, but slowed cycle time may significantly hinder our ability to catch new test failures on time.</div>

</blockquote><div><br></div><div>I don't agree, but it doesn't really matter for the current conversation. We can have this discussion when it actually becomes a problem. </div></div><br>