[webkit-dev] "Tools/Scripts/webkit-patch rebaseline-expectations" does not launch html comparison page?

[Elliot Poger]

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 <abarth at webkit.org> wrote:

> On Tue, Nov 8, 2011 at 1:00 PM, Elliot Poger <epoger at 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 <dpranke at chromium.org>
> wrote:
> >> On Tue, Nov 8, 2011 at 12:24 PM, Adam Barth <abarth at webkit.org> wrote:
> >> > On Tue, Nov 8, 2011 at 12:20 PM, Tony Chang <tony at chromium.org>
> wrote:
> >> >> On Tue, Nov 8, 2011 at 12:00 PM, Elliot Poger <epoger at 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111115/b94d018a/attachment.html>