> >>Basically of the N dependees that a project could dork up, M (M<=N)
> >>dependees could be affected by that project's failure (with N - M being
> >>dorked up by some earlier dependency). Do *not* ask me how we get 2 and
1.
> >>Some optimization perhaps (this determination once cost far too many
> >>cycles). This ought be added to JIRA.
> >
> >
> > Ok, correction .. and this isn't so hard ... affected includes "self",
> > dependees does not, hence the extra '1'.
>
> I still don't understand the difference.
Each project with N dependees can (if it fails) become the 'root cause'
(first problem) for itself and up to N dependees. The actual number it is
the root cause for is usually less than N because some other dependency
failed.
Say we have three projects, that build in this order:
1) X fails
2) Y fails
3) Z (which depends upon both X and Y)
we'd see:
X: affects 2 (self + Z), dependees 1 (Z)
Y: affects 1 (self), dependees 1 (Z)
Z: affects 0, dependees 0.
Basically we can have lots of dependees, but if we are the root cause for
only a few, we are lower 'priority' to fix. This counter was for trying to
allow Gumpmeisters to pick candidates to work upon.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
