Re: [webkit-dev] LayoutTests results fallback graph
On 2011-07-10, at 18:21, Adam Barth wrote: > On Sun, Jul 10, 2011 at 6:20 PM, Mark Rowe wrote: >> On 2011-07-10, at 17:54, Adam Barth wrote: >>> Yes. As I said before: >>> >>> On Sun, Jul 10, 2011 at 3:23 PM, Adam Barth wrote: 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. >> >> Great. Then I'd suggest we fix the Chromium Windows fallback path since >> there are reasons not to change the regular Windows fallback path. > > Ok. Thanks for taking the time to understand the issue. Hopefully you'll remember this exchange in the future when you're about to send out mysterious, unlabeled diagrams :) - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 6:20 PM, Mark Rowe wrote: > On 2011-07-10, at 17:54, Adam Barth wrote: >> Yes. As I said before: >> >> On Sun, Jul 10, 2011 at 3:23 PM, Adam Barth wrote: >>> 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. > > Great. Then I'd suggest we fix the Chromium Windows fallback path since > there are reasons not to change the regular Windows fallback path. Ok. Thanks for taking the time to understand the issue. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On 2011-07-10, at 17:54, Adam Barth wrote: > Yes. As I said before: > > On Sun, Jul 10, 2011 at 3:23 PM, Adam Barth wrote: >> 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. Great. Then I'd suggest we fix the Chromium Windows fallback path since there are reasons not to change the regular Windows fallback path. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
Yes. As I said before: On Sun, Jul 10, 2011 at 3:23 PM, Adam Barth wrote: > 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. Adam On Sun, Jul 10, 2011 at 5:09 PM, Mark Rowe wrote: > 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 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 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 wrote: >>> On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe wrote: > On Jul 10, 2011, at 14:27, Adam Barth wrote: >> On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: >>> On Jul 10, 2011, at 13:57, Adam Barth wrote: On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 >> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
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 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 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 wrote: >> >>> On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe wrote: On Jul 10, 2011, at 14:27, Adam Barth wrote: > On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: >> On Jul 10, 2011, at 13:57, Adam Barth wrote: >>> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 > 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
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 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 wrote: > >> On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe wrote: >>> On Jul 10, 2011, at 14:27, Adam Barth wrote: On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: > On Jul 10, 2011, at 13:57, Adam Barth wrote: >> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
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 wrote: > On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe wrote: >> On Jul 10, 2011, at 14:27, Adam Barth wrote: >>> On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: On Jul 10, 2011, at 13:57, Adam Barth wrote: > On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 2:50 PM, Mark Rowe wrote: > On Jul 10, 2011, at 14:27, Adam Barth wrote: >> On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: >>> On Jul 10, 2011, at 13:57, Adam Barth wrote: On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Jul 10, 2011, at 14:27, Adam Barth wrote: > On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: >> On Jul 10, 2011, at 13:57, Adam Barth wrote: >>> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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. 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. - Mark Sent from my iPhone ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 2:06 PM, Mark Rowe wrote: > On Jul 10, 2011, at 13:57, Adam Barth wrote: >> On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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. The solid arrows at the "normal" transitive fallback path. For example, mac-leopard falls back to mac-snowleopard, which falls back to mac, which falls back to all (the platform independent results). Some directories have non-transitive fallback paths, which a indicated in dashed lines. For example, chromium-mac-snowleopard falls back to chromium-mac, which falls back to chromium. However, the next step in the fallback path depends on where the path started. If the path started at chromium-mac-leopard, the next step in the fallback is to mac-snowleopard whereas if the path started at chromium-mac, the next step in the path is to mac-snowleopard. Similarly, if we arrive at chromium by falling back via chromium-win (regardless of how we got to chromium-win), the next steps in the fallback path is win, mac, and, finally, "all". IMHO, these non-transitive fallback paths are nutty and not worth their complexity. Now, suppose we disabuse the chromium fallback paths of their nuttiness and have every fallback path that transits "chromium" have "all" as its next step, then we'll have a reasonably understandable fallback system, with the sole exception of "win" being strangely captive on "mac-snowleopard". In practice, there's extremely little actual difference (e.g., just one image baseline) between "mac" and "mac-snowleopard", so changing "win" to fallback to "mac" has very little operational cost. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Jul 10, 2011, at 13:57, Adam Barth wrote: > On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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? - Mark Sent from my iPhone > > Having the fallback graph not be a tree causes some strange and > confusing anomalies, which I'd be happy to explain if you don't see > the value in using a fallback tree rather than a fallback DAG. > > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 1:26 PM, Mark Rowe 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 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.) Having the fallback graph not be a tree causes some strange and confusing anomalies, which I'd be happy to explain if you don't see the value in using a fallback tree rather than a fallback DAG. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
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 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. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 1:07 PM, Mark Rowe wrote: > On 2011-07-10, at 12:46, Adam Barth wrote: >> On Sun, Jul 10, 2011 at 12:38 PM, Mark Rowe wrote: >>> On 2011-07-10, at 10:52, Adam Barth wrote: Hi webkit-dev, In trying to understand how our LayoutTest results system works, I've created a digram of the fallback graph among the various platform-specific directories: https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US Unfortunately, the fallback graph is not a tree, as one might imagine initially. I'd like to propose two small changes, which will hopefully make the system more sensible globally. I'm happy to do all the work required to make these changes: 1) The "win" port should fall back either to "all" (the platform independent results) or to "mac," but not to "mac-snowleopard", as it does currently. (I slightly prefer "all", but "mac" would also be fine with me.) >>> >>> I'd argue that falling back to "mac" doesn't make any sense. The >>> regression tests are run against a WebKit using the latest shipping >>> Safari's version of the underlying dependencies. That almost always >>> corresponds to the latest shipping Mac OS X release's components, and not >>> to the components from future versions of Mac OS X. >> >> There appears to be almost zero practical different between "win" >> falling back to "mac" versus falling back to "mac-snowleopard": >> >> abarth@quadzen:~/git/webkit/LayoutTests/platform$ find mac -name "*.png" | >> wc -l >> 6688 >> abarth@quadzen:~/git/webkit/LayoutTests/platform$ find >> mac-snowleopard/ -name "*.png" | wc -l >> 3 > > I'm not sure what that is meant to convey. What you're proposing is changing > the fallback path for the Windows port from one that is conceptually correct > with one that is incorrect. Neither your emails so far nor the diagram in > your initial message have provided any explanation as to why this is. > Perhaps you'd like to expand on what purpose this proposed change has and > what benefits it would provide. Sure. I'll highlight the relevant section of my original email: On Sun, Jul 10, 2011 at 10:52 AM, Adam Barth 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. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On 2011-07-10, at 12:46, Adam Barth wrote: > On Sun, Jul 10, 2011 at 12:38 PM, Mark Rowe wrote: >> On 2011-07-10, at 10:52, Adam Barth wrote: >>> Hi webkit-dev, >>> >>> In trying to understand how our LayoutTest results system works, I've >>> created a digram of the fallback graph among the various >>> platform-specific directories: >>> >>> https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US >>> >>> Unfortunately, the fallback graph is not a tree, as one might imagine >>> initially. I'd like to propose two small changes, which will >>> hopefully make the system more sensible globally. I'm happy to do all >>> the work required to make these changes: >>> >>> 1) The "win" port should fall back either to "all" (the platform >>> independent results) or to "mac," but not to "mac-snowleopard", as it >>> does currently. (I slightly prefer "all", but "mac" would also be >>> fine with me.) >> >> I'd argue that falling back to "mac" doesn't make any sense. The regression >> tests are run against a WebKit using the latest shipping Safari's version of >> the underlying dependencies. That almost always corresponds to the latest >> shipping Mac OS X release's components, and not to the components from >> future versions of Mac OS X. > > There appears to be almost zero practical different between "win" > falling back to "mac" versus falling back to "mac-snowleopard": > > abarth@quadzen:~/git/webkit/LayoutTests/platform$ find mac -name "*.png" | wc > -l >6688 > abarth@quadzen:~/git/webkit/LayoutTests/platform$ find > mac-snowleopard/ -name "*.png" | wc -l > 3 I'm not sure what that is meant to convey. What you're proposing is changing the fallback path for the Windows port from one that is conceptually correct with one that is incorrect. Neither your emails so far nor the diagram in your initial message have provided any explanation as to why this is. Perhaps you'd like to expand on what purpose this proposed change has and what benefits it would provide. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 12:38 PM, Mark Rowe wrote: > On 2011-07-10, at 10:52, Adam Barth wrote: >> Hi webkit-dev, >> >> In trying to understand how our LayoutTest results system works, I've >> created a digram of the fallback graph among the various >> platform-specific directories: >> >> https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US >> >> Unfortunately, the fallback graph is not a tree, as one might imagine >> initially. I'd like to propose two small changes, which will >> hopefully make the system more sensible globally. I'm happy to do all >> the work required to make these changes: >> >> 1) The "win" port should fall back either to "all" (the platform >> independent results) or to "mac," but not to "mac-snowleopard", as it >> does currently. (I slightly prefer "all", but "mac" would also be >> fine with me.) > > I'd argue that falling back to "mac" doesn't make any sense. The regression > tests are run against a WebKit using the latest shipping Safari's version of > the underlying dependencies. That almost always corresponds to the latest > shipping Mac OS X release's components, and not to the components from future > versions of Mac OS X. There appears to be almost zero practical different between "win" falling back to "mac" versus falling back to "mac-snowleopard": abarth@quadzen:~/git/webkit/LayoutTests/platform$ find mac -name "*.png" | wc -l 6688 abarth@quadzen:~/git/webkit/LayoutTests/platform$ find mac-snowleopard/ -name "*.png" | wc -l 3 > I also think that falling back to "all" would only be advisable if we were to > also switch Windows DRT away from the legacy Mac-style form controls and > rebaseline all of the Windows test results. We've shied away from this in the > past because it would result in a big increase in the number of > Windows-specific results. I suspect there's actually an invisible "apple" port (which is a peer to "chromium", "gtk", and "qt") that should hold those common baselines. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On 2011-07-10, at 10:52, Adam Barth wrote: > Hi webkit-dev, > > In trying to understand how our LayoutTest results system works, I've > created a digram of the fallback graph among the various > platform-specific directories: > > https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US > > Unfortunately, the fallback graph is not a tree, as one might imagine > initially. I'd like to propose two small changes, which will > hopefully make the system more sensible globally. I'm happy to do all > the work required to make these changes: > > 1) The "win" port should fall back either to "all" (the platform > independent results) or to "mac," but not to "mac-snowleopard", as it > does currently. (I slightly prefer "all", but "mac" would also be > fine with me.) I'd argue that falling back to "mac" doesn't make any sense. The regression tests are run against a WebKit using the latest shipping Safari's version of the underlying dependencies. That almost always corresponds to the latest shipping Mac OS X release's components, and not to the components from future versions of Mac OS X. I also think that falling back to "all" would only be advisable if we were to also switch Windows DRT away from the legacy Mac-style form controls and rebaseline all of the Windows test results. We've shied away from this in the past because it would result in a big increase in the number of Windows-specific results. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 12:11 PM, Adam Barth wrote: > On Sun, Jul 10, 2011 at 12:01 PM, James Robinson wrote: >> On Jul 10, 2011 10:53 AM, "Adam Barth" wrote: >>> Hi webkit-dev, >>> >>> In trying to understand how our LayoutTest results system works, I've >>> created a digram of the fallback graph among the various >>> platform-specific directories: >>> https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US >>> >>> Unfortunately, the fallback graph is not a tree, as one might imagine >>> initially. I'd like to propose two small changes, which will >>> hopefully make the system more sensible globally. I'm happy to do all >>> the work required to make these changes: >>> >>> 1) The "win" port should fall back either to "all" (the platform >>> independent results) or to "mac," but not to "mac-snowleopard", as it >>> does currently. (I slightly prefer "all", but "mac" would also be >>> fine with me.) >>> >>> 2) The "chromium" port should fall back directly to "all" rather than >>> taking a detour through various Apple-maintained ports, as it does >>> currently. >>> >>> 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. >>> B) The Chromium port will behave more like the other ports (e.g., GTK >>> and Qt), rather than being a parasite on Apple-maintained ports. >>> >>> These changes might increase the number of image baselines we store in >>> the tree for "chromium-mac"-derived ports (because there will be fewer >>> redundant fallback paths), but I expect that cost to be relatively >>> small because essentially every port has different image baselines >>> anyway >> >> Could you measure this? I suspect that not falling back on the mac pixel >> results will mean checking in a few thousand more pngs, but that's just a >> guess. > > That seems possible: > > abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-mac$ find . > -name "*.png" | wc -l > 900 > abarth@quadzen:~/git/webkit/LayoutTests/platform/mac$ find . -name > "*.png" | wc -l > 6688 > abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-win$ find . > -name "*.png" | wc -l > 5988 > abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-linux$ find > . -name "*.png" | wc -l > 5731 > > However, I would expect those savings to disappear once we finish > moving chromium-mac to Skia. More numbers for scale: abarth@quadzen:~/git/webkit/LayoutTests/platform/qt$ find . -name "*.png" | wc -l 3852 abarth@quadzen:~/git/webkit/LayoutTests/platform$ find chromium* -name "*.png" | wc -l 14653 abarth@quadzen:~/git/webkit/LayoutTests/platform$ find . -name "*.png" | wc -l 35350 Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Sun, Jul 10, 2011 at 12:01 PM, James Robinson wrote: > On Jul 10, 2011 10:53 AM, "Adam Barth" wrote: >> Hi webkit-dev, >> >> In trying to understand how our LayoutTest results system works, I've >> created a digram of the fallback graph among the various >> platform-specific directories: >> https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US >> >> Unfortunately, the fallback graph is not a tree, as one might imagine >> initially. I'd like to propose two small changes, which will >> hopefully make the system more sensible globally. I'm happy to do all >> the work required to make these changes: >> >> 1) The "win" port should fall back either to "all" (the platform >> independent results) or to "mac," but not to "mac-snowleopard", as it >> does currently. (I slightly prefer "all", but "mac" would also be >> fine with me.) >> >> 2) The "chromium" port should fall back directly to "all" rather than >> taking a detour through various Apple-maintained ports, as it does >> currently. >> >> 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. >> B) The Chromium port will behave more like the other ports (e.g., GTK >> and Qt), rather than being a parasite on Apple-maintained ports. >> >> These changes might increase the number of image baselines we store in >> the tree for "chromium-mac"-derived ports (because there will be fewer >> redundant fallback paths), but I expect that cost to be relatively >> small because essentially every port has different image baselines >> anyway > > Could you measure this? I suspect that not falling back on the mac pixel > results will mean checking in a few thousand more pngs, but that's just a > guess. That seems possible: abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-mac$ find . -name "*.png" | wc -l 900 abarth@quadzen:~/git/webkit/LayoutTests/platform/mac$ find . -name "*.png" | wc -l 6688 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-win$ find . -name "*.png" | wc -l 5988 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-linux$ find . -name "*.png" | wc -l 5731 However, I would expect those savings to disappear once we finish moving chromium-mac to Skia. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Jul 10, 2011 10:53 AM, "Adam Barth" wrote: > > Hi webkit-dev, > > In trying to understand how our LayoutTest results system works, I've > created a digram of the fallback graph among the various > platform-specific directories: > > https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US > > Unfortunately, the fallback graph is not a tree, as one might imagine > initially. I'd like to propose two small changes, which will > hopefully make the system more sensible globally. I'm happy to do all > the work required to make these changes: > > 1) The "win" port should fall back either to "all" (the platform > independent results) or to "mac," but not to "mac-snowleopard", as it > does currently. (I slightly prefer "all", but "mac" would also be > fine with me.) > > 2) The "chromium" port should fall back directly to "all" rather than > taking a detour through various Apple-maintained ports, as it does > currently. > > 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. > B) The Chromium port will behave more like the other ports (e.g., GTK > and Qt), rather than being a parasite on Apple-maintained ports. > > These changes might increase the number of image baselines we store in > the tree for "chromium-mac"-derived ports (because there will be fewer > redundant fallback paths), but I expect that cost to be relatively > small because essentially every port has different image baselines > anyway Could you measure this? I suspect that not falling back on the mac pixel results will mean checking in a few thousand more pngs, but that's just a guess. - James > > Thoughts? > Adam > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] LayoutTests results fallback graph
Hi webkit-dev, In trying to understand how our LayoutTest results system works, I've created a digram of the fallback graph among the various platform-specific directories: https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US Unfortunately, the fallback graph is not a tree, as one might imagine initially. I'd like to propose two small changes, which will hopefully make the system more sensible globally. I'm happy to do all the work required to make these changes: 1) The "win" port should fall back either to "all" (the platform independent results) or to "mac," but not to "mac-snowleopard", as it does currently. (I slightly prefer "all", but "mac" would also be fine with me.) 2) The "chromium" port should fall back directly to "all" rather than taking a detour through various Apple-maintained ports, as it does currently. 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. B) The Chromium port will behave more like the other ports (e.g., GTK and Qt), rather than being a parasite on Apple-maintained ports. These changes might increase the number of image baselines we store in the tree for "chromium-mac"-derived ports (because there will be fewer redundant fallback paths), but I expect that cost to be relatively small because essentially every port has different image baselines anyway. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
