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

[Adam Barth]

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
>
>