[Webkit-unassigned] [Bug 58122] chromium rebaseline script did the wrong thing with snowleopard expectations

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 12 17:17:02 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=58122





--- Comment #6 from Dirk Pranke <dpranke at chromium.org>  2011-04-12 17:17:02 PST ---
(In reply to comment #5)
> In theory the new rebaseline tool would handle this case correctly. Results from a chromium-snow-leopard bot wouldn't make it into the chromium-mac directory unless all the children of chromium-mac had equal results in them.
> 

Ack, no, that's not what should happen. Until Lion is released, chromium-mac-snowleopard (the port) stores its baselines in chromium-mac (the directory). So, it is okay for a test to exist in both chromium-mac and chromium-mac-leopard.

> The algorithm that the new tool uses is
> 
> 1. Construct a tree out of all the baseline search paths for all the ports
> 2. Retrieve new baselines for the given platforms and insert them into this in-memory tree in the port-specific result directory
> 3. Dedupe
> 
> So if I understand correctly [1] this case should work.
>

Your understanding of [1] matches mine, and I think that it is even correct :)

That said, how do you know if there are "new" baselines? Given that the checked-in baseline in chromium-mac (the directory) currently passes on chromium-mac-leopard (the bot), there are no "new" leopard baselines until after the snowleopard versions overwrite the leopard versions, and the leopard bot starts to fail.

-- Dirk

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list