Re: [Gdbheads] Trust

[Stan Shebs]

Ian Lance Taylor wrote:

> You speculated that trust may be lacking due to internal Red Hat
> politics and/or interactions between engineers and management at Red
> Hat.  I would instead speculate that trust may be lacking because
> people seem to be, to a small degree, scoring points on one another,
> which then raises the possibility that their technical decisions are
> being distorted.  I stress that I'm not saying that anybody's
> technical decisions are in fact being distorted.  What I am saying is
> that some people may be thinking that that is happening.
But why would anybody want to be scoring points in the first place?
Somehow the idea of winning and losing has contaminated what would
normally be a cooperative effort.

> However, this is not the basic disagreement I have with your note.  I
> don't think the lack of trust (if indeed it exists) is the deepest
> underlying problem.  I think it is a consequence, not a root cause.
>
> I think the root cause is that gdb has a leadership vacuum.
From what I can tell, we have a number of warm bodies wanting to
exercise some leadership, but their attempts to do so turn into
fights. What would be the underlying attitude that would cause
that? Why wouldn't Andrew welcome Jim or Michael's ideas, or vice
versa?

I'm going to post a separate analysis of the current maintenance
structure; your insight is most cogent. I think it's also the case
that we've set Andrew up to not be successful in the way he would
like, and we ought to fix it for his sake.

> However, I do not personally find it to be an encouraging sign that
> both Jim and Andrew are on the steering committee.  That raises the
> possibility that the same difficulties which beset the global
> maintainers will simply graduate into the steering committee.  In
> fact, we see this happening as Jim is trying to get the same proposal
> which he made for the gdb maintainers in place on the steering
> committee--i.e., voting.  I fear that Andrew's natural move will be to
> refuse to assent to the voting scheme, and to effectively insist on
> consensus.  The result is deadlock.  Eventually Andrew requests
> reassignment to a different project, and gdb loses his very effective
> services as architect.
It would indeed be unfortunate; hopefully Andrew's commitment to
GDB is strong enough to want to come up with creative solutions
for the deadlock.

> I don't think that we, the free software community, or RMS, the person
> who picks the gdb steering committee, are making the best possible
> choices here.  It will be interesting to see how this plays out.
It's never too late to make suggestions!

Stan