WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
80932
Rebaselining for a new port doesn't work right with multiple fallback ports
https://bugs.webkit.org/show_bug.cgi?id=80932
Summary
Rebaselining for a new port doesn't work right with multiple fallback ports
Ojan Vafai
Reported
2012-03-12 19:58:34 PDT
Rebaselining for a new port doesn't work right with multiple fallback ports
Attachments
Patch
(14.21 KB, patch)
2012-03-12 20:00 PDT
,
Ojan Vafai
abarth
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ojan Vafai
Comment 1
2012-03-12 20:00:13 PDT
Created
attachment 131499
[details]
Patch
Adam Barth
Comment 2
2012-03-12 22:15:28 PDT
Comment on
attachment 131499
[details]
Patch It looks like you didn't add any tests for this new functionality.
Adam Barth
Comment 3
2012-03-12 22:20:36 PDT
Comment on
attachment 131499
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=131499&action=review
> Tools/ChangeLog:10 > + Since chromium-leopard also falls back to mac-leopard, we need to > + copy the existing result for both chromium-leopard and chromium-snowleopard > + before doing lion rebaselines.
I see. Soooo complicated. At some point we should decide that being parasitic on apple-mac isn't worth the complexity.
> Tools/Scripts/webkitpy/tool/commands/rebaseline.py:71 > + def _copy_existing_baseline(self, platforms_to_move_existing_baselines_to, test_name, suffix):
This seems very likely to create non-optimized baselines. Is there an optimization step to clean up after these moves? Moving baselines around is pretty complicated. That's why, in the other class, I went with the approach of preparing the whole move and then double-checking that I didn't break anything (by seeing that the before/after results were the same). I wonder if an approach that would be useful here... One last comment is that this command has grown out of control. It really needs to be refactored into smaller interacting pieces rather than having all the logic in one giant class. (That's perhaps a yak for another day, however.)
Ojan Vafai
Comment 4
2012-03-13 11:20:48 PDT
(In reply to
comment #3
)
> (From update of
attachment 131499
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=131499&action=review
> > > Tools/ChangeLog:10 > > + Since chromium-leopard also falls back to mac-leopard, we need to > > + copy the existing result for both chromium-leopard and chromium-snowleopard > > + before doing lion rebaselines. > > I see. Soooo complicated. At some point we should decide that being parasitic on apple-mac isn't worth the complexity.
I was thinking it would be good to only ever fallback to platform/mac. That would make all the chromium ports' fallbacks form a tree. Would that make all the ports' fallbacks form a tree?
> > Tools/Scripts/webkitpy/tool/commands/rebaseline.py:71 > > + def _copy_existing_baseline(self, platforms_to_move_existing_baselines_to, test_name, suffix): > > This seems very likely to create non-optimized baselines. Is there an optimization step to clean up after these moves?
webkit-patch optimize-baselines does. In practice, this is only ever called from garden-o-matic, which optimizes the baselines.
> Moving baselines around is pretty complicated. That's why, in the other class, I went with the approach of preparing the whole move and then double-checking that I didn't break anything (by seeing that the before/after results were the same). I wonder if an approach that would be useful here... > > One last comment is that this command has grown out of control. It really needs to be refactored into smaller interacting pieces rather than having all the logic in one giant class. (That's perhaps a yak for another day, however.)
I'd rather not invest too much more effort into this code. It's only hit when bringing up a new port and hopefully we'll fix our fallback order to be more of a tree in the not too distant future.
> It looks like you didn't add any tests for this new functionality.
Whoops. Will add a test and then commit.
Ojan Vafai
Comment 5
2012-03-13 11:34:16 PDT
Committed
r110585
: <
http://trac.webkit.org/changeset/110585
>
Adam Barth
Comment 6
2012-03-13 13:30:31 PDT
> I was thinking it would be good to only ever fallback to platform/mac. That would make all the chromium ports' fallbacks form a tree. Would that make all the ports' fallbacks form a tree?
That's an interesting idea. It might work well. We wouldn't quite be left with a tree, but we'd be much, much closer (and could probably clean up the remaining non-tree paths).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug