[webkit-dev] LayoutTests results fallback graph

[Mark Rowe]

Ok, the fact that chromium-win's fallback behaviour uses win results but doesn't match win's fallback behaviour is what I was missing. Couldn't we also address that by changing the behaviour of chromium-win?

- Mark

Sent from my iPhone

On Jul 10, 2011, at 15:55, Adam Barth <abarth at webkit.org> wrote:

> Because the LayoutTest fallback graph is a mess, hence this email thread.  :)
> 
> More proximately, because when the "chromium-mac-leopard" (for
> example) fallback path flows through "mac-leopard", it flows to
> "mac-snowleopard" alongside the fallback path that originates with
> "mac-leopard".  Now, in the case of "win", when the "chromium-win"
> (for example) fallback path flows through "win", it flows thereafter
> to "mac" directly whereas the fallback path that originates with "win"
> takes a detour by way of "mac-snowleopard".  The fact that these two
> fallback paths diverge at this point is one of the reasons the
> fallback graph is not a tree.
> 
> Adam
> 
> 
> On Sun, Jul 10, 2011 at 3:32 PM, Mark Rowe <mrowe at apple.com> wrote:
>> We seem to be talking past one another. Why are there two edges originating at win, but not mac-leopard?
>> 
>> Sent from my iPhone
>> 
>> On Jul 10, 2011, at 15:23, Adam Barth <abarth at webkit.org> wrote:
>> 
>>> On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe <mrowe at apple.com> wrote:
>>>> On Jul 10, 2011, at 14:27, Adam Barth <abarth at webkit.org> wrote:
>>>>> On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe <mrowe at apple.com> wrote:
>>>>>> On Jul 10, 2011, at 13:57, Adam Barth <abarth at webkit.org> wrote:
>>>>>>> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe <mrowe at apple.com> wrote:
>>>>>>>> On 2011-07-10, at 13:20, Adam Barth wrote:
>>>>>>>>> Sure.  I'll highlight the relevant section of my original email:
>>>>>>>>> 
>>>>>>>>> On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth <abarth at webkit.org> wrote:
>>>>>>>>>> These changes have the following virtues:
>>>>>>>>>> 
>>>>>>>>>> A) The resulting fallback graph will be a tree, making the fallback
>>>>>>>>>> graph easier to understand for both humans and automated tools.
>>>>>>>> 
>>>>>>>> I don't see how Windows falling back to mac-snowleopard has any effect on that.  It's no different than mac-leopard in that regard.  Then again, maybe the diagram is trying to convey something that I'm missing due to having no idea what the difference is between the myriad of different line styles in the diagram.
>>>>>>> 
>>>>>>> Notice that the circle for "win" has two arrows emanating from it.
>>>>>>> One of those arrows goes to "mac" and the other goes to
>>>>>>> "mac-snowleopard".  That means that of the fallback paths that transit
>>>>>>> "win", one path flows through "mac-snowlepard" where as the remainder
>>>>>>> flow through "mac".  If we change "win" to fall back to "mac", then
>>>>>>> the graph becomes more tree-like.  (If make change (2) as well, then
>>>>>>> the graph globally becomes a tree.)
>>>>>> 
>>>>>> Can you please clarify what the edges in your diagram, along with what the different line styles, represent?
>>>>> 
>>>>> Sure.
>>>> 
>>>> Thanks. My confusion here comes from the idea that Windows falling back on SnowLeopard causes some sort of "non-tree"-like complexity that other platforms falling back via SnowLeopard aren't also subject to. The behaviour of Leopard and Windows seems incredibly similar in this regard so I'm very unclear as to why only Windows is problematic.
>>> 
>>> Being a tree is a global property, not a local property.  There are
>>> two edges emanating from "win".  In order for the graph to be a tree
>>> one of them must be removed.  Neither one, in isolation, makes the
>>> graph not a tree.
>>> 
>>>> There's an additional confusing element here:  Only a subset of Lion-specific results are currently checked in. The difference between mac and mac-snowleopard results is likely much bigger than you realise.
>>> 
>>> Ah, well, I, of course, can't see invisible results.
>>> 
>>> Adam
>>