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 as well.
On Wed, Apr 11, 2012 at 2:09 PM, Tony Payne <tpa...@chromium.org> wrote: > All code I'm changing is inside of #if PLATFORM(CHROMIUM) blocks. > > Thanks for the quick answer. > > Tony > > > On Wed, Apr 11, 2012 at 2:03 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> On Wed, Apr 11, 2012 at 1:57 PM, Tony Payne <tpa...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev