On Tue, Nov 8, 2011 at 1:00 PM, Elliot Poger <epo...@chromium.org> wrote: > How do the gardeners do the rebaselining currently? It seems like what I'm > looking for is pretty much akin to gardening...
They use garden-o-matic, which displays the diffs prior to conducting the rebaseline. > I have looked at http://www.chromium.org/developers/how-tos/webkit-gardening > , but I have no idea if it is current. It is current. Adam > On Tue, Nov 8, 2011 at 3:31 PM, Dirk Pranke <dpra...@chromium.org> wrote: >> On Tue, Nov 8, 2011 at 12:24 PM, Adam Barth <aba...@webkit.org> wrote: >> > On Tue, Nov 8, 2011 at 12:20 PM, Tony Chang <t...@chromium.org> wrote: >> >> On Tue, Nov 8, 2011 at 12:00 PM, Elliot Poger <epo...@chromium.org> >> >> wrote: >> >>> Perhaps I should approach this from a different angle: >> >>> What is the recommended procedure for: >> >>> - generating new baseline images for a few dozen failing tests, on >> >>> various >> >>> platforms >> >> >> >> webkit-patch rebaseline-expectations >> >> >> >>> - visually inspecting them to make sure they're not bogus >> >> >> >> Would 'webkit-patch pretty-diff' work for you? It should show the >> >> files >> >> being added/deleted, but it won't generate a pixel diff. >> > >> > The tricky part is that this view requires you to understand all the >> > fallback behavior among different ports. My sense is that this would >> > be easier if we had a smarter view that understood that and presented >> > it to the user in an understandable way. Unfortunately, no one has >> > built that view yet. >> >> rebaseline-chromium-webkit-tests had some careful logging to stdout >> that explained what files were (or weren't) being updated and why >> (i.e., I claim that I had solved this problem in that script. Although >> it wasn't presented in the HTML, that wouldn't have been that hard to >> add). >> >> I think if we could get the equivalent into the new tool, and if we >> could separate the update and optimize steps, that would probably be >> good enough. I think combining update and optimize makes it *very* >> hard to determine the correctness of what you've done. >> >> In other words, my ideal workflow would be update --> review & approve >> --> optimize --> [optionally review optimze?] --> land. >> >> -- Dirk > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev