Re: [Gdbheads] proposed change to GDB maintainership rules

[Ian Lance Taylor]

David Carlton <address@hidden> writes:

> I don't entirely agree with this.  My impression is that there was a
> fairly strong feeling that some sort of conflict resolution mechanism
> was necessary, basically to prevent Andrew from having his way
> whenever conflicts arose.  That's certainly the way I feel; I actually
> don't come into conflict with Andrew very often, but I've seen it
> happen to others on the list.  (I got the impression that other
> people, people who have had more interaction with Andrew in the past,
> felt more strongly than I did that we must have a way to prevent
> Andrew from always having his way in disputes; perhaps others could
> speak up to correct me on this matter?)

Well, now we are talking about a different problem.  Thanks for making
that clear.

The only problem I saw clearly stated before was ``it takes too long
for gdb patches to get approved.''

You are now stating a completely different and seemingly unrelated
problem, which might be written down as ``Andrew [Cagney] gets his way
whenever conflicts arise, and he is not always right.''

Do other people on this mailing list agree that this is a problem?
Have I stated it correctly, or is there some more precise way to
describe the problem?


I can see why voting might apply to this problem, where I didn't see
why voting would apply to the previously stated problem.

I'll beat a dead horse here by saying that first you state the problem
clearly, then you find the solution.  If you don't state the problem
clearly, then the solution doesn't make sense.


If I have stated this problem correctly, then I can see several
possible solutions.

* Realize that Andrew is generally right.

* Convince Andrew to realize that in some cases he may be wrong.

* If Andrew won't permit some patches to be checked in, have other
  global maintainers start approving patches, and trust that Andrew
  will not simply revert them, particularly if he is alone in his
  opposition.

* If Andrew checks in bad patches, then when and if he does so, revert
  them, and trust that he will not persevere, particularly if he is
  alone in his opposition.

* Remove Andrew as a global maintainer.

* Create a gdb steering committee.  Appeal to it when there are
  unresolvable conflicts.  The steering committee holds straight up
  and down votes when consensus can not be achieved.

* Permit relevant maintainers to vote on patch approval (this is the
  proposal on the table).

* People who can't work with Andrew stop working on gdb.

* Fork gdb.

As I write these (and I haven't exhausted the list by any means), it's
clear that these solutions actually address various different
problems.  So would anybody like to clarify the problem further?  What
aspect of Andrew's behaviour seems unacceptable?  That is, what sorts
of conflicts does he always get his way on?  It might help to point to
some examples on public mailing lists, if there are any.


> You've proposed consensus or tyranny as alternatives.  I personally
> would be against those choices - consensus isn't a conflict resolution
> mechanism at all, the only obvious candidate for tyrant is Andrew, and
> even if there were other obvious candidates, I just don't like
> tyrants.

I would say that consensus is a conflict resolution mechanism if there
is mutual respect and trust, and if everybody approaches problems in a
spirit of fairness.  It may be that mutual respect and trust has been
lost in the gdb team.  It may be that not everybody is approaching
problems with a spirit of fairness.

As a past tyrant myself, I believe that tyranny is generally the best
solution, but it has an important precondition, which is that the
tyrant is almost always right.  When that is not the case, or when
people do not believe that it is the case, then tyranny fails.  To
govern requires the consent of the governed.  Evidently people are not
willing to accept Andrew as a tyrant, either because he is not almost
always right, or because people do not believe that he is almost
always right.

> GCC's steering committee seems to work for it, so maybe we
> could adopt an approach like that; my main request there is that I
> would like the steering committee membership to better reflect the
> current active members of the GDB community.

I may be misunderstanding your point here, but I want to note that the
point of a steering committee is not to reflect the active developers.
The point is to reflect the different user communities.  It is
sensible to have developers on the steering committee.  But it is
essential to include people who can speak for different user
communities, even if they are not active developers.  For example, on
the gcc steering committe, Torbjorn Granlund, Marc Lehmann, David
Miller, and Joel Sherrill hardly contribute any patches at all (and
that may be true of others on the committee as well).  They are on the
committee to give a voice to particular constituencies.

Ian