Re: [Gdbheads] proposed change to GDB maintainership rules

[Jim Blandy]

I don't think Andrew Cagney is well-suited for the tyrant's position.

Andrew works very hard, and has contributed a lot to GDB.  I think the
gdbarch system and the new frame unwinding system are substantial
internal improvements to GDB.  His technical judgement is usually
good.  And it's clear that he's personally committed to forwarding
Project GNU's interests.

But despite these strengths, I think he has some weaknesses that make
him unsuitable as a tyrant.

Andrew is very poor at explaining himself.  Your experiences trying to
talk with him in this discussion are pretty typical.  On technical
issues, he often has difficulty building support for the projects that
he undertakes, because people don't really understand where he's
going.  On management issues, he cannot explain why the policies he
sets are beneficial; it took me forever to figure out why he believes
that his having the final say on patch review protects GDB against
inappropriate corporate influence (I now gather it comes down to, "I,
personally, can be trusted to do so", which is interesting in itself),
and I'm still mystified as to why area maintainers overriding global
maintainers weakens this protection, as he says it would.

Andrew is poor at taking technical criticism into account.  He often
seems unable to understand points people raise.  Andrew's technical
judgement is usually good, but when it falters, it takes a coordinated
effort to do anything about that.  For example, GDB's stack frame
model now has an unnecessary "sentinel frame", whose presence
complicates code throughout GDB's core.  When Andrew first presented
his plans for retrofitting the stack frame model, I tried to either
understand why the sentinal frame was needed, or explain why I thought
it wasn't.  Andrew's response was to say, over and over again, that
"the stack is a recursive data structure", which didn't help in either
direction.  It simply wasn't a conversation that went anywhere.  The
effort required, and the slim chance of success, made me reluctant to
get involved in such conversations at all.

Other GDB contributors have had similar experiences.  For example:
http://sources.redhat.com/ml/gdb-patches/2003-11/msg00001.html
http://sources.redhat.com/ml/gdb-patches/2003-05/msg00268.html

My point isn't that Andrew should be superhuman, and never make
mistakes.  It is rather that it shouldn't take a campaign to get him
to listen.

Andrew is too comfortable making fiats.  He instates policy changes
without much apparent care for whether those policy changes have much
support.  People raise concerns, and he answers, but he doesn't seem
to care whether people have been persuaded, or whether they have just
given up.  Michael Snyder has brought up Andrew's change to the
maintainership policy earlier in this thread, which I think is an
example of this.

Andrew is satisfied with simply replying to people; he is unconcerned
with whether he has addressed their concerns or not.  People have
tried to raise the procedural issues that precipitated this whole
discussion on the ordinary GDB mailing lists several times, and get
them resolved in the usual ways.  I've included links to some of the
recent discussions below.  In each case, Andrew Cagney replied,
indicating that he felt nothing should be changed.  Eventually, people
got frustrated, and decided to put their heads together in private to
assemble a proposal they could stand behind.

    "[maint] The GDB maintenance process"
        Daniel Jacobowitz <address@hidden>
        http://sources.redhat.com/ml/gdb/2003-02/msg00277.html

    "[maint] GDB needs more local maintainers"
        David Carlton <address@hidden>
        http://sources.redhat.com/ml/gdb/2003-02/msg00528.html

    "Re: Tracepoint support in Cygnus GDB ?"
        Eli Zaretskii <address@hidden>
        http://sources.redhat.com/ml/gdb/2003-09/msg00335.html

In the end, if a group of eight long-standing contributors to GDB feel
they have no choice but to organize in private to get their concerns
heard by the tyrant, then I think it's clear that that person is not
the tyrant GDB needs.

If GDB is to have a tyrant, I think they should be someone who:
- works hard on GDB, and has experience with many different areas of
  it (as Andrew does),
- can clearly explain the positions they take,
- is good at understanding and addressing other people's points, and
  is willing to set their preferences aside when there's a consensus
  against them, and
- can work with the group to choose policies people respect.

---

When talking about our proposal, we had hoped, perhaps naïvely, that
merely imposing a voting system, without naming names, would merely
make Cagney's success in pursuing his projects depend on his ability
to present them, persuade people they were the right thing, and
address issues raised in a friendly way.  That way, we could keep the
aspects of the status quo we liked --- Cagney's contributions and
expertise --- and moderate the aspects we didn't like --- explained
above.

But voting doesn't work well in high-contention environments; if
introducing voting produces too much acrimony, then it's self-
defeating.  And I don't think we've managed to introduce our proposal
very smoothly.  I think that the strongest remaining argument for
voting is that this situation would have been less likely to arise,
had our procedure provided for voting in the first place.

I think it's very unlikely that we can continue with the status quo,
and work things out now that problems have been aired.  I have
photographs of a friendly meeting of the GDB hacking community in a
park in Sunnyvale, from five years ago or so.  From there, things have
deteriorated to this point.  I don't see this discussion encouraging
anyone on either side to change their feelings, so I don't see why
that trajectory would change if the status quo persists.