[webkit-dev] Process for making changes that affect layout test results
ojan at chromium.org
Wed Apr 11 14:13:17 PDT 2012
Typically, if you're working on Chromium Linux or Win, you'd include the
new expected results for that platform in your initial commit/code-review
On Wed, Apr 11, 2012 at 2:09 PM, Tony Payne <tpayne at chromium.org> wrote:
> All code I'm changing is inside of #if PLATFORM(CHROMIUM) blocks.
> Thanks for the quick answer.
> On Wed, Apr 11, 2012 at 2:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Wed, Apr 11, 2012 at 1:57 PM, Tony Payne <tpayne at chromium.org> wrote:
>>> Given the recent discussion on test_expectations.txt, perhaps the answer
>>> to my question is still up in the air.
>>> I'm working on a change that I expect to require changing the
>>> expectations for about 75 tests on chromium win and linux.
>>> https://trac.webkit.org/wiki/Rebaseline seems to only cover the
>>> gardening work to rebaseline after the commit. I cannot find any wiki pages
>>> that describe what the original author is expected to do when making visual
>>> changes. Should I attempt to rebaseline manually? Should I mark the tests
>>> as failing? Should I just check in and let the bots go red?
>> Just land the patch and rebaseline the tests. Please also coordinate with
>> Chromium port's WebKit gardener when landing this patch.
>> Also, does this patch only affect Chromium Windows and Linux, and not
>> GTK, Qt, Windows, etc...? If the answer is no, and will affect other
>> non-Chromium ports, then you're also responsible for rebaselining or
>> coordinating with other ports to make sure you don't break tests on their
>> ports as well.
>> - Ryosuke
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev