Re: [Gdbheads] Trust

[Ian Lance Taylor]

Stan Shebs <address@hidden> writes:

> I've been pondering a while just what it is that people are really
> unhappy about, and I think the deepest underlying problem is a lack of
> trust. You see it in the desire to have private meetings, in the
> accusations about cabals, attempts at public censure, and so forth.

Yours was a thoughtful note, but I don't think I agree with you.

I agree with you that there appears to be a lack of trust at this
point.  I don't think that trust is completely gone, but I think it is
partially gone.

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.

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.

I think that any ongoing technical project requires a person or set of
people who say "this change is OK" or "this change is not OK".  A
couple of months ago I referred to this person as a tyrant, but it can
also be a set of oligarchs; I'll stick with tyrant for simplicity.
Another possible name would simply be maintainer, but a maintainer
also has other duties.  Anyhow, these decisions have to be made with
regard to generally understood project goals; if people disagree
significantly on the goals, the project forks (this type of fork is
normally beneficial, e.g., FreeBSD vs. NetBSD).  The tyrant has to be
able to clearly explain the rationale behind each decision; if this
can not be done, people question the decisions, and the project loses
focus.

Any ongoing technical project also requires a person or set of people
who do architectural design and programming.  In free software these
are normally, though not always, the same people.  I'll use the word
architect for simplicity.  The architect obviously needs the
cooperation of the maintainer.  In many projects, the architect is the
maintainer.  But the roles are clearly distinct, even though the lines
blur in practice.

Anyhow, it should be pretty obvious at this point where I am going.
Andrew is serving the role of architect for gdb.  I see some
questioning here and there, but generally people seem to feel that
Andrew has a clear vision for gdb going forward, and, while there is
clearly disagreement on some details, I don't know of any strong
disagreement on the overall direction.  I also don't know of any
strong alternative proposals for direction.  (There have been such
proposals in the past, such as the libgdb approach which I think was
originally from Tom Lord--and didn't some guy named Blandy do a bunch
of work along those lines later on?  But I don't see anybody strongly
pushing a vision other than Andrew's today.  No doubt somebody will
correct me if I am wrong here.)

Andrew is also currently serving as the tyrant for gdb.  He is the
person who ultimately says "this change is OK" or "this change is not
OK".  It's true that there are various other maintainers.  But as we
can see in the current discussion over who should be a symtab
maintainer, Andrew is trying to assert ultimate control over them.
Unfortunately, I think that Andrew is failing one of the requirements
of a tyrant which I mentioned above, to wit, the ability to clearly
explain the rationale behind each decision.

At any rate, that is the common complaint that I'm seeing in these
discussions.  The complaint is not that Andrew makes the wrong
decision or that he makes no decisions at all.  The complaint is that
he does not successfully explain the reasons for his decisions.  And
when faced with questions and challenges, he sometimes simply says
nothing at all.

It feels somewhat odd to be writing about Andrew in this manner in a
discussion which he is reading, not that it's the first time I've done
it.  In fact it seems to me that Andrew is not taking a strong part in
this discussion, even though he is a major topic of discussion.  This
silence leads me to project my own perceptions onto him, rightly or
wrongly.

Anyhow, one result of a tyrant who has trouble clearly explaining the
rationale behind his decisions is that people start to speculate on
why the decisions are being made.  Here we see another origin for the
lack of trust.

The original revolutionary proposal had two parts: global maintainers
have blanket write privileges, and disagreements are resolved by vote.
Both of those can easily be interpreted as attempts to replace Andrew
in the role of tyrant, first by extending the role of tyrant to more
people, and second by providing a clear mechanism to overrule Andrew
and to force him to either explain his decisions or face being
overruled.

Obviously, to the extent that I am correct, the long-term solution is
to split the role of architect and tyrant for gdb.  This has been done
for gcc.  The tyrant is clearly the steering committee as a whole, but
few members of the committee, perhaps none, make major architectural
decisions.  It is possible that the same approach could work for gdb.

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.

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 is, perhaps, unfortunate that free software has gotten to the point
where these decisions directly affects people's livelihood.  This
tends to preclude the other natural solution to this type of conflict,
in which one or more parties simply pick up their marbles and go home.

Ian