Re: Maintainer policy for GDB

[Joel Brobecker <brobecker at adacore dot com>]

I'll try to put all the comments I have after having read the various
messages that were posted.

Overall, I like the proposal.

> Patch Champions
> 
> These volunteers track all patches submitted to the gdb-patches list.  They
> endeavor to prevent any posted patch from being overlooked; work with
> contributors to meet GDB's coding style and general requirements, along with
> FSF copyright assignments; remind (ping) responsible maintainers to review
> patches; and ensure that contributors are given credit.

I really like this idea. I can help out if nobody else volunteers.

> Some maintainers are listed as responsible for patch review in particular
> areas.  If a maintainer is not currently able or willing to review patches,
> please contact the global maintainers or the steering committee, who will
> resolve the situation and find a replacement or assistant if necessary.

I'm a bit unclear as who it is who should contact the GM or the SC.
Is it the patch champion, or the submitter, or both?

I'm more inclined to say "contact the GMs" first, and they will contact
the SC if appropriate. Like some of us said previously, I'd like to keep
the requests to the SC only for occasions where only the SC can solve
the situation. If things can be sorted out by the GMs, let's do it that
way, as they have a better knowledge of the GDB community.

> Separating responsibility for patch review from authority for patch review
> is a new concept for GDB; I believe the suggestion was Ian's.  The more time
> I've spent working on this proposal the more I've come to like it.  I
> envision the areas of responsibility as broad, but the areas of authority as
> possibly more specialized.

This is a winning concept, in my opinion. I agree with Eli that this
concept needs to be made a little bit clearer, perhaps by adding a
little paragraph, something resembling the above, as an introduction
to the rest of the text. When I read the text, I was clear on what
each category of developers had to do, as well as could do. Reading
that same text after having a clear idea of this concept makes it
have more sense.

> I have always been in favor of the concept that global maintainers
> should be able to approve patches anywhere, without having to wait for
> area maintainers.  If we don't trust each other enough for that, then
> we need to work on the trust and/or the list of maintainers.

Strongly agreed.

About the voting system: I would also prefer to avoid this. The history
of the GDB maintenance community since I joined shows that we're able
to work together without unsolvable disagreements. In case a disagreement
happens and cannot be resolved, which should be very seldom, the persons
involved should present our arguments to the SC, and the SC makes a
decision. They can vote if they want :-) (I heard they have a voting
system in place).

Eli said:
> By contrast, you suggest to begin with unconditional trust.  We
> already tried that in the past, and we saw what happened.  Why try
> that again? why assume that what happened once, cannot happen again?

I agree with Eli that an abusive developer/maintainer may happen again
in the future. But I disagree that we should enforce stricter rules to
prevent this from happening. This would be a waste of everybody's time
for a situation which can only potentially happen very seldomly. How many
developers have been bulies in GDB in the past 5 years?

Let's not penalize the "nice guys", the majority of you, and deal with
the few "bad guys" when the situation demands it. I'll take the example
of something that I believe happened roughly a year ago with GCC. People
complained about abusive commits from one of the global maintainers. I
don't know the exact story, not following closely the GCC mailing lists,
but I think the SC threatened to remove that person from the list of
blanket maintainers, and perhaps even enacted on this decision. In any
case, last I heard, he's playing much nicer now. (I know this guy
personally, so I'm not criticizing him, just using his story as an
example).

So let's say we end up having somebody who is abusive and doesn't change
his behavior after discussing the problem. Then let's collect the evidences
of his behavior, and present them to the SC, who can then decide to revoke
or not the priviledges that he's abusing from.

> (Why CC everyone, if we all read the list?)

I like this practice, because emails with my name in the recipients
have a little flag, so I pay more attention to them (and look at them
first). This is an easy way to make sure that the message gets some
people's attention.

-- 
Joel