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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe <[email protected]> wrote: >>>> On Jul 10, 2011, at 14:27, Adam Barth <[email protected]> wrote: >>>>> On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe <[email protected]> wrote: >>>>>> On Jul 10, 2011, at 13:57, Adam Barth <[email protected]> wrote: >>>>>>> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe <[email protected]> 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 <[email protected]> >>>>>>>>> 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 >> _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
