[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 #10 from Dirk Pranke <dpranke at chromium.org>  2011-04-13 12:44:27 PST ---
(In reply to comment #9)
> > 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
> 
> Ah, I see. Thanks for the explanation!
> 
> > > 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.
> 
> So the problem in abstract terms would be that when rebaselining ports that other ports fall back onto, you can get into an incorrect state. My thinking is that you can't get into an incorrect state if you rebaseline entire trees of dependent ports at once (which is essentially what a request to rebaseline MAC should do).
> 

Yes, I agree that "all at once" should be the safe and right thing to do. I just think we need to stare carefully at whatever algorithm we implement to do everything at once to make sure we're not missing some use case.

And yes, r-c-w-t definitely could use some better logging.

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