Re: Maintainer policy for GDB

[David Carlton <david dot carlton at sun dot com>]

On Wed, 23 Nov 2005 21:34:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: David Carlton <david.carlton@sun.com>
>> Date: Tue, 22 Nov 2005 16:50:41 -0800

>>> How can I shape the documentation according to my ideas if I don't
>>> have the final say?

>> By acting exactly the way you do now.  Anybody paying attention to
>> GDB development knows that you're a very fast and responsive
>> reviewer

> But you see, this ``fast response'' argument works both ways: if I'm
> a fast reviewer, why should it matter that only I can approve
> documentation changes--a few hours of delay cannot possibly hurt
> anyone or anything.

Let me table that for a sec.

> AFAIK and IIRC, Daniel suggested the change we are discussing
> precisely _because_ of too slow response time of some responsible
> maintainers, which was hurting development pace and driving away
> contributors and potential maintainers.

> So let's take my fast response time out of the equation.  Let's
> imagine that it takes me two or three weeks to review a patch.  Or
> let's imagine that I'm ill, or traveling, or otherwise incommunicado
> from time to time.  What would be your answer to my question then?

My answer is that you would be much less effective in shaping the
documentation in those circumstances.  If I were submitting a patch
including documentation, if there was agreement that the
non-documentation parts of the patch were fine, if the documentation
part seemed non-controversial to me, if you didn't respond fairly
quickly to the doc patch, and if I had the authority to commit it all,
I would do so.

Your fast response time is a key factor (though not the only one) in
why I suspect you would still be the major shaper of documentation in
the new system.  (A tangential comment: I think one of the most
important lessons from the agile development community is the vast
benefits of fast feedback.)

...

> In other words (and sorry for over-simplification), you ask me to
> assume that everybody else is nice and reasonable, and that, more
> often than not, I will succeed in talking them into accepting my
> opinions.

I think you will on the matter of documentation, yes.  I'm not so sure
about djgpp - there, I suspect people will still listen to you, but
there's probably more scope for reasonable people to disagree.  (And,
for that matter, for people to act unreasonable.)

> Unfortunately, my experience is that this doesn't exactly
> work that way.  In fact, we invented the maintenance rules and we
> are now rethinking them _precisely_ because the assumption that
> everyone is always nice and reasonable doesn't seem to work too
> well.
...
> I can show examples of arguments, even disputes, with other
> maintainers over issues where belief and personal attitudes
> prevailed over objective reasoning, and we ended up in disagreement.
> In those cases, where I had powers to veto a change, I could have
> things my way, but where I didn't, things got done against my
> opinions.

Right.  And I suspect the proposal's conflict resolution mechanisms
are as good as they could be.  I don't have any great suggestions for
improving them, unfortunately.

To get back to your question that I tabled above:

+ if I'm a fast reviewer, why should it matter that only I can approve
+ documentation changes--a few hours of delay cannot possibly hurt
+ anyone or anything.

My first answer is "you could be wrong about whether a patch is a good
one or not".  Personally, I would (strongly) prefer not to adopt a
conflict resolution mechanism where we designate certain people as
always winning arguments about specific areas of GDB.

My second answer is "you and documentation are both unique".  If we
were to adopt the new proposal with a modification that "Eli Zaretskii
is the only person allowed to approve doc patches", I'm pretty sure
that would be just fine, maybe even better than the proposal without
that modification.  But you respond faster than any other maintainer,
and (I'm pretty sure) we're much less likely to get into substantive
disagreement over doc changes than changes to other areas of the code.
So I'm pretty leery about generalizing from that example.  (Which is,
admittedly, unfair of me, given that I started this subthread exactly
by asking you to talk more about that example!)

> So these things can and did happen, and I don't think it's fair to
> ask someone to take responsibility for some part of GDB and at the
> same time to tell them they should expect to fight with others who
> have write access and who just happen to respond faster to RFAs.

I have two different responses to this.

1) We could go along with that, and not ask anybody to take
   responsibility: we could have a notion of authorized committer
   without any notion of responsible committer.  That wouldn't bother
   me at all; the proposal seems slightly too complex for me as-is, so
   I wouldn't mind simplifying it in that way.

2) It's not obvious to me that asking people to be responsible is
   unfair.  And, as long as people have the right to say "no, I don't
   want to be responsible" and remain authorized to commit patches,
   it's also not obvious to me that it's urgent for us to figure out
   whether or not it's fair.  Why not leave it up to people to decide
   if they want to take responsibility without being given any
   additional authority in return?

David Carlton
david.carlton@sun.com