I finally got back to this and tried to use garden-o-matic. I launched it ("./Tools/Scripts/webkit-patch garden-o-matic") and it did nothing. I opened a separate thread about this: http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/a64eabe35e59ac17#('garden-o-matic does nothing?')
Thus I am still unable to rebaseline tests across multiple platforms. Is there a technique that actually works, with tools that exist today? On Tue, Nov 8, 2011 at 4:08 PM, Adam Barth <aba...@webkit.org> wrote: > 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