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

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Dirk Pranke <dpranke at chromium.org>  2011-04-12 22:25:36 PST ---
(In reply to comment #7)
> (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-*.
> 

No, this is very much by design. See the writeup I sent to chromium-dev a couple weeks ago for the rationale on this:

http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/52a01dd2c7380457/a6f57f5b912b9cc8?lnk=raot&pli=1

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

Yes.

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

I don't know that this will work as a general rule, but it might. This is part of the destabilization I was concerned about before.

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