Ok, so FOG as successes/(failures+prereqs) hasn't been a huge hit w/ folks, but what about:
successes/(successes+failures+prereqs). This is really (if my math memory is ok) 'odds of a successful build, based off history' -- I think. This is far more valuable as a FOG Factor, because it is something bounded (0 to 1) and something we can do math with. I think 'likelihood of success' is good to know, but also if you combine it with 'likelihood of dependent success' (a multiplication of all direct dependencies) one gets a comparison of how precariously something sits on it's stack, and how much it contributes to success or failure. I feel there is good information in there. We ought know (mathematically) that Forrest or Maven don't have a snowballs chance in heck of building, and it isn't their doing. We ought know what odds we are facing at a certain depth. A short while back I introduced 'dependency depth', and I display that plus the total dependency depth (a sum of the direct dependencies depth.) (See some below). I think these (plus perhaps average depth of direct dependencies) are good number to have. A project might be a heavy re-user, and how many dependencies it has is important to know. I think I need to generate stats pages that compare these, so we get a fair picture. Ant: a.. Dependency Depth: 9 a.. Total Dependency Depth: 31 Batik: a.. Dependency Depth: 12 a.. Total Dependency Depth: 39 Forrest: a.. Dependency Depth: 23 a.. Total Dependency Depth: 64 Maven: a.. Dependency Depth: 20 a.. Total Dependency Depth: 321 The math isn't jumping out right now but some combination of 'liklihood of success' plus 'dependency depth' (or their sums/averages) seems appropriate for analysis of a project's 'state of play' within Gump. Even without this final level, I feel there is important (if subjective) insight I could imaging a dependency diagram with these numbers indicated (perhaps as colours or link thickness) that showed us an interesting overview of a project. I suspect that some statistical analysis could be done around clusters, search for hot/cold spots in a graph, but that math I don't have available in my head. I suspect these metrics are contributors to that though. BTW: I am not sure if these ought only be tracked over the last 30 or 90 days, or over all Gumping. Right now, to do a range like this would require the historical results database since counters loose that information. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]