[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 20:04:44 PDT 2011


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





--- Comment #7 from James Kozianski <koz at chromium.org>  2011-04-12 20:04:44 PST ---
(In reply to comment #6)
> 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.

Ah, okay. Would it be possible to change this behaviour? It seems simpler if all builders point to a specific directory (ie: the port they themselves are running), and we have directories like chromium-mac as nothing more than a shorthand for chromium-mac-*.

So the correct behaviour in this situation is to put the SL results in chromium-mac, and move the original chromium-mac results into chromium-mac-leopard? Or in other words, before overwriting results in directory X, copy those results to all the directories that currently fall back onto X. It shouldn't be too hard to add that logic to the new tool.


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

I'm glad. Sometimes these rebaseline discussions can be hard to follow :-)

> 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.

The new tool has an understanding of the complete fallback order, so it will be able to tell that changing chromium-mac will also change chromium-mac-leopard if the latter is empty and we can add custom logic for handling those cases (such as the logic described above).

-- 
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