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]
