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

[Adam Barth]

On Tue, Nov 8, 2011 at 12: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.

I'm not religious about the specifics of the workflow.  The limiting
factor here is someone deciding to spend time solving the problem.

Adam