On Tue, Apr 10, 2012 at 11:42 AM, Stephen Chenney <span dir="ltr"><<a href="mailto:schenney@chromium.org">schenney@chromium.org</a>></span> wrote:<div class="gmail_quote"><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 Tue, Apr 10, 2012 at 1:00 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">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>On Tue, Apr 10, 2012 at 6:10 AM, Stephen Chenney <span dir="ltr"><<a href="mailto:schenney@chromium.org" target="_blank">schenney@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




There is a significant practical problem to "turn the tree red and work with someone to rebaseline the tests". It takes multiple hours for some bots to build and test a given patch. That means, at any moment, you will have maybe tens and in some cases hundreds of failing tests associated with some changelist that you need to track on the bots. You might have more failing tests associated with a different changelist, and so on.</blockquote>




<div><br></div></div><div>But you have to do this for non-Chromium ports anyway because they don't use test_expectations.txt and skipping the tests won't help you generate new baseline. In my opinion, we should not further diverge from the way things are done in other ports.</div>


</div></blockquote><div><br></div></div><div>How long on average does it take a builder to get through a change on another port? Right now the Chromium Mac 10.5 and 10.6 dbg builds are processing a patch from about 3 hours ago. About 20 patches have gone in since then. For the Mac 10.5 tree to ever be green would require there being no changes at all requiring new baselines for a 3 hour window.</div>


<div><br></div><div>Just because other teams do it some way does not mean that Chromium, with it's greater number of bots and platforms, should do it the same way.</div></div></blockquote><div><br></div><div>Yes, it does mean that we should do it the same way. What if non-Chromium ports started imposing arbitrary processes like this on the rest of us? It'll be a total chaos, and nobody would understand the right thing to do for all ports.</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>We are discussing a process here, not code, and in my mind the goal is to have the tree be as green as possible with all failures tracked with a "minimal" expectations file and as little engineer time as possible.</div>

</div></blockquote><div><br></div><div>That's not our project goal. We have continuous builds and regression tests to prevent regressions to improve the stability, not to keep bots green. Please review <a href="http://www.webkit.org/projects/goals.html">http://www.webkit.org/projects/goals.html</a></div>

<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>Just look at how often the non-chromium mac and win builds are red. In particular, changes submitted via the commit queue take an indeterminate amount of time to go in, anything from an hour to several hours. Patch authors do not necessarily even have control over when the CQ+ is given.</div>

</div></blockquote><div><br></div><div>That's why I don't use commit queue when I know my patch requires platform-dependent rebaselines.</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>Even when manually committing, if it takes 3 hours to create baselines then no patches go in in the afternoon. What if the bots are down or misbehaving?</div></div></blockquote><div><br></div>

<div>We need to promptly fix those bots.</div><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>I would also point out the waste of resources when every contributor needs to track every failure around commit time in order to know when their own changes cause failures, and then track the bots to know when they are free to go home.</div>

</div></blockquote><div><br></div><div>But that's clearly stated in the contribution guide line.</div><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 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>Why not simply attach an owner and a resolution date to each expectation? The real problem right now is accountability and a way to remind people that they have left expectations hanging.</div>


</blockquote><div><br></div></div><div>That's what WebKit bugs are for. Ossy frequently files a bug and cc'es the patch author when a new test is added or a test starts failing and he doesn't know whether new result is correct or not. He also either skips the test or rebaseline the test as needed. He also reverts patches when the patch clearly introduced serious regressions (e.g. crashes on hundreds of tests).</div>


</div></blockquote><div><br></div></div><div>Yes, Ossy does an excellent job of gardening. Unfortunately, on Chrome we have tens if not hundreds of gardeners and, as this thread has revealed, no clear agreement on the best way to garden.</div>

</div></blockquote><div><br></div><div>That IS the problem. We have too many in-experiented gardeners that don't understand the WebKit culture or the WebKit process.</div><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>I strongly believe that keeping the tree green is more important than having a clean expectations file.</div></div></blockquote><div><br></div><div>I disagree. You're effectively just disabling the test temporarily.</div>

<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>Finally, there is no pain free way to do this. The question is how to distribute the pain. Right now each gardening is using a process that distributes pain in their preferred way. From a community standpoint it would be nice if the Chromium team could come up with something consistent.</div>

</div></blockquote><div><br></div><div>The process Chromium port uses should be consistent with non-Chromium ports.</div><div><br></div><div>- Ryosuke</div><div><br></div></div>