Adam R. B. Jack wrote:

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)

wait, this does not compute: Y affects 2 (self + Z). The fact that Z was already affected should not change the situation.

Z: affects 0, dependees 0.

projects effect themselves or not?

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 is not the case at all! The gump-importance of a project is how many *total* projects potentially depend on its success, not the first-level affected ones.

Think about it:

 case 1)

     a <- b
     b <- c1
     b <- c2
     b <- c3
     b <- c4
     c4 <- d1
     c4 <- d2
     c4 <- d3
     c4 <- d4

 case 2)

     a <- b
     a <- c
     a <- d

you are telling me that you consider case 1 to be less of a priority than case 2!?! [no wonder why we were never able to build cocoon]

In graph theory, there is the notion of "betweeness" of a graph node that is the number of paths from a node to every other node that pass thru this one.

in case 1) a has betweeness 9 while in case 2) a has betweeness 3

betweenness is used in social networks to study the "importance" of a particular node or in infection networks to understand the "importance to a disease immunity" of a particular agent.

in gump, it is true that solving a in case one might unlock only b, while in case 2) might unlock b,c and d but this is just wishful thinking, because down the road, unlockin b in case 1 unlocks far more people.

Look at xom today:

 affected: 0
 dependees: 138

and it's the *LAST ONE ON THE LIST* but has some of the highest number of dependees!

Do you understand why this information is misleading? you are telling people that xom doesn't effect anybody [btw, how can this possibly be?], while, in fact, it's basically holding up pretty much *HALF* of the projects that can't build because of it!!!

This counter was for trying to allow Gumpmeisters to pick candidates to work upon.

I wonder if that helped or keep people away from the real critical issues.

--
Stefano.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to