Maintainer policy for GDB

[Daniel Jacobowitz]

We've discussed various times in the past several years whether we needed
to change the maintainer policies for GDB. It's been a little while since
the last time, and a couple things have changed - the set of active
developers is a bit different, and the steering committee is properly in
place now in case of dispute. Let's try again, please.

I have put together one possible alternative, drawing heavily on comments
from Ian, Jim, and Andrew on the steering committee list last year.
Obviously I like my own proposal or I wouldn't be sharing it :-) But I want
to know what everyone else involved thinks!

One of my goals with this proposal is to acknowledge the current reality of
GDB development, which is that no one has very much time for it. I want to
make it easier for those who do have time to make progress, and I want to
make it easier to draw on outside contributions. In the long term, I hope
that this will let us all have more time for GDB, and give it a much-needed
boost.

So, first some proposed text, and then some additional rationale. Please,
let the list know your opinions.

=========================

Working With Other Maintainers

All maintainers are encouraged to post major patches to gdb-patches for
comments, even if they have the authority to commit the patch without
review. This especially includes patches which change internal interfaces
(e.g. global functions, data structures) or external interfaces (e.g. user,
remote, MI, et cetera).

Global Maintainers

The global maintainers may review and commit any change to GDB. For major
changes, or changes to areas with other active developers, global
maintainers are encouraged to post patches for comment and review before
committing.

The global maintainers are responsible for reviewing patches to any area
for which no one else is listed as responsible.

In case of abuse, e.g. committing patches without approval or patches which
go against an agreed-upon and documented roadmap for GDB, global maintainers
have the authority to revert _any_ applied patch. No one may reapply a
reverted patch without either persuading the reverter, or bringing the issue
to the GDB Steering Committee for discussion.

(NOTE: documentation links to roadmap items would be good here; we don't
have any today but we could at least create a placeholder in gdbint.texi for
them. Alternatively, we could use a freeform Wiki for this; that seems to
work well for other projects... END NOTE.)

*LIST*


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.

*LIST*


Changes to the List of Maintainers

Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers. Final authority
resides with the GDB Steering Committee.

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.


Responsible Maintainers

These are active developers who have agreed to review patches to particular
areas of GDB, in which they have particular knowledge and experience. The
areas are expected to be broad; multiple maintainers responsible for an area
may wish to informally subdivide the area further to improve review.

*LIST*


Authorized Committers

These are developers working on particular areas of GDB, who are trusted to
commit their own (or others') patches in those areas without further review
(but see Working With Other Maintainers, above).

*LIST*

=========================

Comments on the text:

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.

The biggest advantage I see in the split is a very clear image of who to
pester about pending patches, which does not necessarily include every GDB
developer who wants to be able to work in that area.


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.


Patch champion is definitely not a role suitable for one person. Just trust
me on this one. Two at minimum. Who else can we get to do it? I don't
know yet but we'll find somebody. I've been doing essentially this for
months and I'm willing to continue as time permits.


I would like for every defined "area" of approval to be fairly well defined,
possibly a specific list of files. I believe it's reasonable to include
most changes to users of an interface under the umbrella of approval which
covers the implementation of the interface, so files which include
maintained headers would be somewhat under the authority of the maintainers
involved. This may need to be clarified.


The set of current maintainers, and their areas, should probably be
consolidated. I have no idea yet how to go about doing this. At a bare
minimum, inactive maintainers should be pinged and pruned, with appropriate
credits in the manual. We have a lot of them right now!


This does not replace the entire explanatory text of the MAINTAINERS file of
course. Bits like the Obvious Fix rule or the bits about Joel's role as RM
would remain. I've just covered the section highlights.

[Jim Blandy]

[sourceware.org blocked my message because it had too many recipients.]

---------- Forwarded message ----------
From: Jim Blandy <***@red-bean.com>
Date: Nov 16, 2005 10:40 PM
Subject: Re: Maintainer policy for GDB
To: ***@sourceware.org, Jim Blandy <***@redhat.com>, Kevin Buettner
<***@redhat.com>, Andrew Cagney <***@gnu.org>, "J.T. Conklin"
<***@acorntoolworks.com>, Fred Fish <***@ninemoons.com>, Mark Kettenis
<***@gnu.org>, Peter Schauer
<***@regent.e-technik.tu-muenchen.de>, Stan Shebs
<***@apple.com>, Michael Snyder <***@redhat.com>, Eli Zaretskii
<***@gnu.org>, Elena Zannoni <***@redhat.com>


I like it overall.

I'm a bit concerned that one global maintainer can, by reverting a
patch, demand to be persuaded, or have the issue kicked to the
steering committee. If at least (say) four global maintainers comment
on the patch and (say) 75% or more of those who comment feel the patch
should go in, shouldn't that be enough to get it in?

I'm sympathetic to complaints that voting systems clutter an otherwise
simple proposal. And I'd hate to disrupt a general consensus on the
rest of the document just because folks disagreed on how voting should
work. But it'd be nice to keep things out of the steering committee
as much as possible, and in the hands of the people doing the
day-to-day development.

[Daniel Jacobowitz]

Post by Jim Blandy
[sourceware.org blocked my message because it had too many recipients.]

Weird, worked for me...

Post by Jim Blandy
I like it overall.
I'm a bit concerned that one global maintainer can, by reverting a
patch, demand to be persuaded, or have the issue kicked to the
steering committee. If at least (say) four global maintainers comment
on the patch and (say) 75% or more of those who comment feel the patch
should go in, shouldn't that be enough to get it in?
I'm sympathetic to complaints that voting systems clutter an otherwise
simple proposal. And I'd hate to disrupt a general consensus on the
rest of the document just because folks disagreed on how voting should
work. But it'd be nice to keep things out of the steering committee
as much as possible, and in the hands of the people doing the
day-to-day development.

I'm not concerned by this. It would be a pretty rude thing to do. If
it happens once, we can handle that going up to the SC; if it happens
repeatedly, we can either clarify the reversion policy or censure the
maintainers involved, depending on the situation.

I absolutely don't want a voting system involved in this process.

[Jim Blandy]

Post by Daniel Jacobowitz
I'm not concerned by this. It would be a pretty rude thing to do. If
it happens once, we can handle that going up to the SC; if it happens
repeatedly, we can either clarify the reversion policy or censure the
maintainers involved, depending on the situation.
I absolutely don't want a voting system involved in this process.

There's no harm in giving it a try.

[Jim Blandy]

Post by Jim Blandy

Post by Daniel Jacobowitz
I'm not concerned by this. It would be a pretty rude thing to do. If
it happens once, we can handle that going up to the SC; if it happens
repeatedly, we can either clarify the reversion policy or censure the
maintainers involved, depending on the situation.
I absolutely don't want a voting system involved in this process.

There's no harm in giving it a try.

This was ambiguous. I don't see any harm in trying things out as you
suggest. If the SC ends up being called on too often, then we can
revisit things.

[Eli Zaretskii]

Date: Thu, 17 Nov 2005 09:03:54 -0500
I absolutely don't want a voting system involved in this process.

Why not?

[Eli Zaretskii]

Date: Wed, 16 Nov 2005 22:40:56 -0800
I'm a bit concerned that one global maintainer can, by reverting a
patch, demand to be persuaded, or have the issue kicked to the
steering committee. If at least (say) four global maintainers comment
on the patch and (say) 75% or more of those who comment feel the patch
should go in, shouldn't that be enough to get it in?

We could restrict the revert rule to those cases where a patch was
committed that is not backed up by anyone except the person who
committed it.

[Daniel Jacobowitz]

Thank you all for the feedback. I'm not responding to everything here,
because I'm interested in Eli's answers to some of Jim's questions;
both of you have more background about the early public development of
GDB than I do. But I'll try to respond to everything else.

[I'm collecting my replies because I've noticed that I, and some of the
rest of us, am prone to conversations with a high branching factor. I
do it myself, but I still find it very hard to follow...]

Post by Eli Zaretskii

Date: Thu, 17 Nov 2005 09:03:54 -0500
I absolutely don't want a voting system involved in this process.

Why not?

Here's the reasons that come to mind:

- Voting systems are slow to use; it takes a long time to get
a reasonable number of responses from developers.

- They require a huge amount of process, structure, and
documentation. I spent a long time getting one adopted
for the steering committee, and I'm not eager to do it again.

- In any dispute among the GDB developers, the SC is available
to resolve the issue. They hold the final word - that's the
FSF's official position. We don't need to be afraid to
invoke the SC; they're here to help.

Post by Eli Zaretskii
(Why CC everyone, if we all read the list?)

Because I wanted to address this jointly to the GDB community, and to
the body of global maintainers - many of whom read the list
sporadically nowadays, or not at all. Which is, perhaps, its own
problem.

Now that some discussion has been generated, I'm trimming back to the
list. Folks will know where to go to see the discussion.

Post by Eli Zaretskii

Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers. Final authority
resides with the GDB Steering Committee.

Does this mean any addition to the list of recognized maintainers must
be brought before the committee for the final approval?

My apologies; Mark had the same question. Obviously I didn't say what
I meant very well. I wanted to suggest that changes to the listed
maintainers be handled by the global maintainers, informally, much as
they are today. But if there is some disagreement, it's clear where
the global maintainers can look for a final word.

"Final authority resides with the GDB SC" really applies to everything
in MAINTAINERS (and, more broadly, to everything in GDB). The FSF's
position is that the steering committee are the "maintainers", and
everyone else are the "developers" - I'm not using that wording because
I find it very confusing.

Post by Eli Zaretskii

Responsible Maintainers
These are active developers who have agreed to review patches to particular
areas of GDB, in which they have particular knowledge and experience. The
areas are expected to be broad; multiple maintainers responsible for an area
may wish to informally subdivide the area further to improve review.
*LIST*

The current list of responsibilities need to be carefully redone, for
this to be effective (you say something similar in the comments, see
below).

Yes, this is absolutely true. If folks like this proposal, or a
revised version with similar language, then we can do that as the next
step.

Post by Eli Zaretskii

Separating responsibility for patch review from authority for patch review
is a new concept for GDB; I believe the suggestion was Ian's.

This separation is not at all clear from the text. I needed to go
back and reread it after reading this comment, but even upon second
reading I'm still not sure what the text really says. Whose
responsibility is it to review patches and who has the authority for
patch review, according to your proposal?
So I think the text should be made more explicit on this; perhaps
simply mention and explain this separation instead of leaving it for
the reader to deduce.

I was a bit short on concrete examples because I didn't have any names
in mind. The responsibility for patch review falls to the people
listed in the "Responsible Maintainers" section, and then to the global
maintainers for any patch without a responsible maintainer listed. The
authority is held by the global maintainers, the responsible
maintainers within their broad areas, and the authorized committers
within their possibly narrower areas.

Is that better? If so I'll try to find clearer wording for the
text.

Post by Eli Zaretskii

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.

The problem is, trust is built by following rules which are initially
intentionally restrictive. As the trust grows, the restrictions can
be gradually lifted.
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?

Jim's already asked the questions I would have asked here; I'll wait
for the two of you to discuss this.

For myself, I do not agree with the former paragraph. For the latter
paragraph, a combination of two things: (A) a hopefully not misguided
sense of hope that we can do better this time; and (B) a clear
statement of where to go in case we can't. The SC is not involved in
day-to-day development and will therefore hopefully be more useful if
outside intervention is called for.

Post by Eli Zaretskii
It would be better to post diffs against the current MAINTAINERS.
Then no one will need to guess what parts are being replaced and which
aren't.

If I did that, people would complain that they couldn't read the
diffs... can't win.

In any case, looking at that file right now, I see these sections:
GDB Steering Committee
Global Maintainers (no text, just a list)
Various Maintainers
The Obvious Fix Rule
Can Commit Without Approval
Target Instruction Set Architectures
Host/Native
Core
UI
Misc
Write After Approval
Release Management
Past Maintainers
Paper Trail

Of those, these I would leave alone:
GDB Steering Committee
The Obvious Fix Rule
Write After Approval
Release Management
Past Maintainers
Paper Trail

I would replace the rest. Some of them contain useful text that should
be preserved somewhere, e.g. the reference to gdb_mbuild.sh, and the
(somewhat brief) list of supported architectures; I don't think
MAINTAINERS is a good place for them.

Post by Eli Zaretskii

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.

I've been doing this; I'd probably continue. I'd welcome your help.
I've been thinking (prompted by an old suggestion of Andrew's, and some
more recent work done by Daniel Berlin for gcc-patches) about
automation; but mostly I get by well enough just using a mailreader.
But more automation may be in the works too.

Post by Eli Zaretskii

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.

That change sounds fine to me.

Post by Eli Zaretskii

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.

OK, thanks, that helps. This does need to go early in the flow for the
later bits to make sense.

Post by Eli Zaretskii

(NOTE: documentation links to roadmap items would be good here; we don't
have any today but we could at least create a placeholder in gdbint.texi for
them. Alternatively, we could use a freeform Wiki for this; that seems to
work well for other projects... END NOTE.)

I think gdbint.texi should document what is implemented, and not what
will be implemented. A Wiki seems to be a more appropriate place for
roadmap items. They can be moved to gdbint.texi when they've been
implemented.

OK. No objection to referencing a Wiki (by nature a live document)
from MAINTAINERS?

Post by Eli Zaretskii

Changes to the List of Maintainers
Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers. Final authority
resides with the GDB Steering Committee.

Is everybody currently on the "Write After Approval" list considered
to be a Maintainer? If so, I don't hope adding someone to that list
will require explicit permision from the SC.

Definitely not. There's a sentence in the current MAINTAINERS about
how to become one; we can update that to be clearer with the new
scheme. I think being approved by anyone on the global maintainers
list should be sufficient - that's what it is in practice today,
anyway. Sound good to you?

Post by Eli Zaretskii

The biggest advantage I see in the split is a very clear image of who to
pester about pending patches, which does not necessarily include every GDB
developer who wants to be able to work in that area.

That's probably a good idea. Right now we have quite a number of
vacua, i.e. areas where it is not clear who to pester. In some cases
that's because no one is listed, in others someone is listed who
hasn't show any recent activity.

Right. I don't want that to happen again.

Post by Eli Zaretskii

I would like for every defined "area" of approval to be fairly well defined,
possibly a specific list of files. I believe it's reasonable to include
most changes to users of an interface under the umbrella of approval which
covers the implementation of the interface, so files which include
maintained headers would be somewhat under the authority of the maintainers
involved. This may need to be clarified.

Do we consider it a as a goal to have someone listed for every "area"
(file?) in gdb?

In my opinion, no. For instance, right now there's no one active on
the list of maintainers who is keeping an eye on MI; therefore I don't
think there's benefit from listing anyone in particular. Bump it up to
the global maintainers, and either someone will handle it, or the patch
champions will pester until it does. [Which when the two sets overlap
may involve the patch champions reviewing a lot of patches to areas
without more specific folks listed; but I deliberately didn't codify
this, there's no need for the two sets to overlap to be effective.]

[Joel Brobecker]

Post by Daniel Jacobowitz

Post by Mark Kettenis
I think gdbint.texi should document what is implemented, and not what
will be implemented. A Wiki seems to be a more appropriate place for
roadmap items. They can be moved to gdbint.texi when they've been
implemented.

OK. No objection to referencing a Wiki (by nature a live document)
from MAINTAINERS?

How about the website itself? Is a Wiki really better for that purpose?

[Daniel Jacobowitz]

Post by Joel Brobecker

Post by Daniel Jacobowitz

Post by Mark Kettenis
I think gdbint.texi should document what is implemented, and not what
will be implemented. A Wiki seems to be a more appropriate place for
roadmap items. They can be moved to gdbint.texi when they've been
implemented.

OK. No objection to referencing a Wiki (by nature a live document)
from MAINTAINERS?

How about the website itself? Is a Wiki really better for that purpose?

I think that a wiki is more useful for something intended to be
free-form and informal, describing the current state of GDB and
people's half-baked plans. The web site should be more polished.

Just my two cents, though.

[Joel Brobecker]

Post by Daniel Jacobowitz

Post by Joel Brobecker
How about the website itself? Is a Wiki really better for that purpose?

I think that a wiki is more useful for something intended to be
free-form and informal, describing the current state of GDB and
people's half-baked plans. The web site should be more polished.

Oh. I think I misunderstood what would go in. I thought they would
be long-term plans aggreed on by the maintainers. Perhaps a Wiki would
indeed be useful to hold a summary of the discussion we had about
overhauling a bit the hppa unwinder. Hmmm....

[Wu Zhou]

Post by Daniel Jacobowitz

Post by Joel Brobecker

Post by Daniel Jacobowitz

Post by Mark Kettenis
I think gdbint.texi should document what is implemented, and not what
will be implemented. A Wiki seems to be a more appropriate place for
roadmap items. They can be moved to gdbint.texi when they've been
implemented.

OK. No objection to referencing a Wiki (by nature a live document)
from MAINTAINERS?

How about the website itself? Is a Wiki really better for that purpose?

I think that a wiki is more useful for something intended to be
free-form and informal, describing the current state of GDB and
people's half-baked plans. The web site should be more polished.
Just my two cents, though.

I buy this idea. :-) IMHO, WiKi at least provides a open and collaborative
platform for document work, which might be helpful for GDB.

Regards
- Wu Zhou

[Andrew STUBBS]

Post by Daniel Jacobowitz

Post by Mark Kettenis
Is everybody currently on the "Write After Approval" list considered
to be a Maintainer? If so, I don't hope adding someone to that list
will require explicit permision from the SC.

Definitely not. There's a sentence in the current MAINTAINERS about
how to become one; we can update that to be clearer with the new
scheme. I think being approved by anyone on the global maintainers
list should be sufficient - that's what it is in practice today,
anyway. Sound good to you?

I don't want to get into the general discussion - it isn't really my
business - but while you are rehashing MAINTAINERS ...

I recently read MAINTAINERS for the first time. From my, not totally
uninitiated, point of view, I have to say that most of it was fairly
clear and understandable.

However, I did have trouble on the above point, while trying to
understand the 'Obvious Fix Rule'. It currently states that all listed
'maintainers' may invoke the rule. When I queried this on the list I was
told that it also applies the the 'Write After Approval' list.

I don't want to get into policy, but a clarification of the text would
be nice. It's just a question of nomenclature really.

Thanks

Andrew Stubbs

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 11:04:54 +0000
However, I did have trouble on the above point, while trying to
understand the 'Obvious Fix Rule'. It currently states that all listed
'maintainers' may invoke the rule. When I queried this on the list I was
told that it also applies the the 'Write After Approval' list.

Are you saying that it was unclear that ``maintainers'' included
``write after approval''? If so, why is that unclear? perhaps because
there's no ``maintainer'' word in ``write after approval''?

[Andrew STUBBS]

Post by Eli Zaretskii

Date: Fri, 18 Nov 2005 11:04:54 +0000
However, I did have trouble on the above point, while trying to
understand the 'Obvious Fix Rule'. It currently states that all listed
'maintainers' may invoke the rule. When I queried this on the list I was
told that it also applies the the 'Write After Approval' list.

Are you saying that it was unclear that ``maintainers'' included
``write after approval''? If so, why is that unclear? perhaps because
there's no ``maintainer'' word in ``write after approval''?

Exactly so. As I understand it, 'write after approval' does not mean
'maintainer'. I see that Mark Kettenis is also unclear on this point.

It certainly isn't a word I would apply to myself, for example, and I am
in that list.

Andrew

[Eli Zaretskii]

Date: Thu, 17 Nov 2005 22:07:11 -0500

Post by Eli Zaretskii

Post by Daniel Jacobowitz
I absolutely don't want a voting system involved in this process.

Why not?

- Voting systems are slow to use; it takes a long time to get
a reasonable number of responses from developers.
- They require a huge amount of process, structure, and
documentation. I spent a long time getting one adopted
for the steering committee, and I'm not eager to do it again.
- In any dispute among the GDB developers, the SC is available
to resolve the issue. They hold the final word - that's the
FSF's official position. We don't need to be afraid to
invoke the SC; they're here to help.

In other words, you find voting (a) inconvenient and (b) unnecessary.
I thought you had more fundamental reasons; ``absolutely don't want''
seemed to imply that.

The responsibility for patch review falls to the people
listed in the "Responsible Maintainers" section, and then to the global
maintainers for any patch without a responsible maintainer listed. The
authority is held by the global maintainers, the responsible
maintainers within their broad areas, and the authorized committers
within their possibly narrower areas.
Is that better?

Sorry, not really. The difference between responsibility for patch
review and authority for patch review is still not clear: it sounds
like they both rest with the same people, responsible maintainers and
global maintainers.

Perhaps we lack a definition of what is included in responsibility and
what is included in authority. The words are similar in semantic
meaning. How about describing the process during which both the
responsibility and the authority are executed?

No objection to referencing a Wiki (by nature a live document) from
MAINTAINERS?

Not from me.

Post by Eli Zaretskii
Do we consider it a as a goal to have someone listed for every "area"
(file?) in gdb?

In my opinion, no. For instance, right now there's no one active on
the list of maintainers who is keeping an eye on MI; therefore I don't
think there's benefit from listing anyone in particular.

Isn't it desirable to have an expert for each area of GDB code? If
not, why not? what are the disadvantages of that? (I don't think this
is directly related to the present discussion, but I was too surprised
to read your negative response to Joel's question to let that go
without understanding it.)

[Daniel Jacobowitz]

Post by Eli Zaretskii

Post by Daniel Jacobowitz
The responsibility for patch review falls to the people
listed in the "Responsible Maintainers" section, and then to the global
maintainers for any patch without a responsible maintainer listed. The
authority is held by the global maintainers, the responsible
maintainers within their broad areas, and the authorized committers
within their possibly narrower areas.
Is that better?

Sorry, not really. The difference between responsibility for patch
review and authority for patch review is still not clear: it sounds
like they both rest with the same people, responsible maintainers and
global maintainers.
Perhaps we lack a definition of what is included in responsibility and
what is included in authority. The words are similar in semantic
meaning. How about describing the process during which both the
responsibility and the authority are executed?

I don't think the words are at all similar in semantic meaning.
Responsibility is an obligation and authority is a privilege.

This would be easier with Venn diagrams, but they don't lend themselves
to email very well. Let me give some examples. Afterwards, I will
attempt to clarify the original descriptions, if these help.

Let's suppose this was the complete list of MAINTAINERS. Please
forgive my unimaginative names.

Global Maintainers:

Bob
Joe
Ellen

Responsible Maintainers:

Bob - Language support
Adam - Symbol readers

Authorized Committers

Charlie - Fortran support
Rick - Stabs support

Patch Champions

Rachel

Now let's look at some patches. Who posts the patch has no effect on
either responsibility or authorization, so let's assume all patches are
posted by an outside contributor. Let's use Fred.

First point to note: one of the global maintainers is also a
responsible maintainer, one of the responsible maintainers is not a
global maintainer. Bob has accepted some more specific
responsibilities in addition to those of the global maintainers,
because of his interest/expertise. Adam is not a global maintainer,
but is the recognized expert on symbol reading issues.

Fred posts a Fortran patch. Charlie can review and approve (or reject)
it if he wants to. However, if the patch sits unreviewed for a week
and Rachel steps in, she won't bug Charlie about it - she might make
sure it was copied to him in case he has comments, but the fact that it
is still pending after a week is not his _responsibility_. Instead,
she will poke Bob about it, because he is responsible for seeing that
language patches get reviewed. She will not poke the global
maintainers about it, because there is a more specific responsible
party for language patches. If he's on vacation, et cetera, then the
global maintainers will be available as backup.

Fred posts a CLI interface patch. If this one goes unreviewed, Rachel
will ping the global maintainers about it, because there is no more
specific responsible party.

The two highlights are a clear set of who to contact when a patch goes
unreviewed, and the option for developers to contribute to GDB without
having obligations for patch review for other contributors forced upon
them.

Post by Eli Zaretskii

Post by Daniel Jacobowitz
No objection to referencing a Wiki (by nature a live document) from
MAINTAINERS?

Not from me.

OK, I think everyone's happy on this point. Stan poked the overseers
list about a Wiki last month; I'm going to follow up on that.

Post by Eli Zaretskii

Post by Daniel Jacobowitz

Post by Mark Kettenis
Do we consider it a as a goal to have someone listed for every "area"
(file?) in gdb?

In my opinion, no. For instance, right now there's no one active on
the list of maintainers who is keeping an eye on MI; therefore I don't
think there's benefit from listing anyone in particular.

Isn't it desirable to have an expert for each area of GDB code? If
not, why not? what are the disadvantages of that? (I don't think this
is directly related to the present discussion, but I was too surprised
to read your negative response to Joel's question to let that go
without understanding it.)

Perhaps we're just using "goal" differently.

In the current set of developers, there are many (huge) areas of GDB in
which no one is taking an active role. Having someone listed for, say,
MI who is not actively interested in the future of MI offers no benefit
over leaving the review of MI patches to global maintainers, and some
downside - one more delay in the process of getting MI patches
reviewed, with no value added.

Now, if we had someone who was actively interested in this area, and
who was willing and able to review patches, I'd leap at the chance to
list them. And MI wasn't a great example, because I hope that we will
have MI maintainers again in the next year or so; both Nick and Bob
obviously have long-term interests in MI. But I don't think it likely
that this will happen for every piece of GDB at the same time, and
there are a lot of fiddly little bits that don't compartmentalize
easily.

[Ian Lance Taylor]

Date: Fri, 18 Nov 2005 10:26:18 -0500
I don't think the words are at all similar in semantic meaning.
Responsibility is an obligation and authority is a privilege.

What I meant was that the expression of their meaning is similar: it's
who reviews patches, right?

I'm not sure what you mean, but I think that I do understand what
Daniel means.

If you are "responsible" for patch review in a specific area, it means
that you have promised that you will review all patches in that area
in a reasonably timely fashion.

If you are "authorized" to commit patches in a specific area, it means
that you can commit patches without anybody else's approval. And
those patches can be your patches or somebody else's patches. But you
have not made any promise as to reviewing other people's patches.

At least in the U.S., anybody is "authorized" to make a citizen's
arrest if they see a crime being committted. But only the police are
"responsible" for doing so. If a civilian sees a crime being
committed and does nothing, nothing happens to the civilian. If a
policeman sees a crime being committed and does nothing, he gets fired
from his job.

This would be easier with Venn diagrams, but they don't lend themselves
to email very well. Let me give some examples. Afterwards, I will
attempt to clarify the original descriptions, if these help.

Sorry, I must be too dumb today. In the example you've given, who has
the ``authority for reviewing patches''?

Bob, Joe, Ellen, Adam, Charlie, and Rick are all authorized to review
patches. But only Bob and Adam are responsible for it.

To be authorized to commit means that you *may* review patches. To be
responsible for patch review means that you *must* review patches.

Ian

[Eli Zaretskii]

Date: 18 Nov 2005 10:44:05 -0800
If you are "responsible" for patch review in a specific area, it means
that you have promised that you will review all patches in that area
in a reasonably timely fashion.
If you are "authorized" to commit patches in a specific area, it means
that you can commit patches without anybody else's approval.

Thanks, I think I understand now. What fooled me was that Daniel said
"authority to review patches", not "authority to commit patches". And
since almost anyone can comment on a patch posted to gdb-patches, it
wasn't clear what kind of authority we were talking about.

At least in the U.S., anybody is "authorized" to make a citizen's
arrest if they see a crime being committted. But only the police are
"responsible" for doing so. If a civilian sees a crime being
committed and does nothing, nothing happens to the civilian. If a
policeman sees a crime being committed and does nothing, he gets fired
from his job.

But, unless I'm mistaken, Daniel didn't suggest to ``fire'' the
responsible person(s) in our case, did he? So the analogy is not
really full; in particular, what kind of responsibility is that if you
aren't going to be fired for failing to do that for which you are
responsible?

[Daniel Jacobowitz]

Post by Eli Zaretskii

Post by Ian Lance Taylor
If you are "responsible" for patch review in a specific area, it means
that you have promised that you will review all patches in that area
in a reasonably timely fashion.
If you are "authorized" to commit patches in a specific area, it means
that you can commit patches without anybody else's approval.

Thanks, I think I understand now. What fooled me was that Daniel said
"authority to review patches", not "authority to commit patches". And
since almost anyone can comment on a patch posted to gdb-patches, it
wasn't clear what kind of authority we were talking about.

Ahh! Thanks, that's very helpful feedback. I've been using "review"
sloppily when I really mean "approve and apply, or reject".

Post by Eli Zaretskii

Post by Ian Lance Taylor
At least in the U.S., anybody is "authorized" to make a citizen's
arrest if they see a crime being committted. But only the police are
"responsible" for doing so. If a civilian sees a crime being
committed and does nothing, nothing happens to the civilian. If a
policeman sees a crime being committed and does nothing, he gets fired
from his job.

But, unless I'm mistaken, Daniel didn't suggest to ``fire'' the
responsible person(s) in our case, did he? So the analogy is not
really full; in particular, what kind of responsibility is that if you
aren't going to be fired for failing to do that for which you are
responsible?

You are mistaken. It's not a zero-tolerance policy, of course, but if
you are listed as responsible and not doing your job, the global
maintainers or SC should address it:

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.

This is one of the big differences that having clearly listed
responsibility gives us. We don't have to take away their commit
access just to resolve this particular problem.

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 13:51:35 -0500
Eli, if this helps, here's another sort of example: someone who has
done a lot of work in an area, and who we trust to make changes to that
area without review, might be listed as "authorized to commit". But
that person may either be uninterested in reviewing other people's
changes (unfortunate; I'm not sure how I'd feel about this case in
practice), not very good at reviewing other people's changes, or simply
always too busy to review other people's changes. So listing them as
the responsible maintainer would do a disservice to the rest of the
community.

I'm worried that people might not want to take the responsibility upon
them if others, who don't share the responsibility, are allowed to
commit changes nonetheless.

In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Fri, 18 Nov 2005 13:51:35 -0500
Eli, if this helps, here's another sort of example: someone who has
done a lot of work in an area, and who we trust to make changes to that
area without review, might be listed as "authorized to commit". But
that person may either be uninterested in reviewing other people's
changes (unfortunate; I'm not sure how I'd feel about this case in
practice), not very good at reviewing other people's changes, or simply
always too busy to review other people's changes. So listing them as
the responsible maintainer would do a disservice to the rest of the
community.

I'm worried that people might not want to take the responsibility upon
them if others, who don't share the responsibility, are allowed to
commit changes nonetheless.
In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

I hope:
- People who want to help improve the quality of GDB by adding
long-term consistency to some area.
- People who feel personally involved in some particular area of GDB
development, probably because of large contributions to it.

It may not have its own authority, but it does have a certain amount of
face-recognition value, too. Anyway, I don't want to write an essay on
free software motivations here :-)

Here's the counter question: if we force people to take the
responsibility, why will they do a good job? Today's example is
convincing to me: they won't. Let the people who want to do it
take responsibility voluntarily.

[Daniel Jacobowitz]

Date: Fri, 18 Nov 2005 16:46:20 -0500
Here's the counter question: if we force people to take the
responsibility, why will they do a good job?

I wasn't suggesting to force a responsibility. And we cannot enforce
it, anyway, under your suggestions, since being authorized means to
have the same rights with less duties. We all are busy people, so
it's quite possible we will wind up with several authorized
maintainers and no responsible maintainers.

For that, all I have to offer you is that there's no way to end up as a
global maintainer without accepting this responsibility. Of course
it's diffused across the entire group of GMs, but that's always been
the case.

If in practice it turns out we don't have anyone in this slot, I don't
think the system will fall apart; although I think it would be better
for GDB if we did have some.

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 17:41:38 -0500

Date: Fri, 18 Nov 2005 16:46:20 -0500
Here's the counter question: if we force people to take the
responsibility, why will they do a good job?

I wasn't suggesting to force a responsibility. And we cannot enforce
it, anyway, under your suggestions, since being authorized means to
have the same rights with less duties. We all are busy people, so
it's quite possible we will wind up with several authorized
maintainers and no responsible maintainers.

For that, all I have to offer you is that there's no way to end up as a
global maintainer without accepting this responsibility.

(I think we are talking in circles.) If becoming a global maintainer
won't give me anything, not even a T-shirt, why would I want to become
one?

In other words, some incentive, small as it may be, might help us
bring more responsible maintainers on board. We should think about
something, some authority, that we leave to the global/responsible
maintainers and to them alone. Something like design decisions,
perhaps, I dunno.

If in practice it turns out we don't have anyone in this slot, I don't
think the system will fall apart; although I think it would be better
for GDB if we did have some.

Do others share this view? Taking this to the extreme, can we
maintain GDB without any GM at all? (Although, if there's no real
difference between ``authorized'' and ``responsible'' but the title,
perhaps the answer to this is trivial.)

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 16:46:20 -0500
Here's the counter question: if we force people to take the
responsibility, why will they do a good job?

I wasn't suggesting to force a responsibility. And we cannot enforce
it, anyway, under your suggestions, since being authorized means to
have the same rights with less duties. We all are busy people, so
it's quite possible we will wind up with several authorized
maintainers and no responsible maintainers.

[Jim Blandy]

Post by Eli Zaretskii
In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

People who take pleasure in being helpful to the project, and to Free
software. People who want to establish a name for themselves as a
reliable contributor. There are a lot of reasons people contribute to
Free software projects; I don't think the pursuit of authority is even
a particularly common motivation.

Not everyone finds authority to be a perk. I don't enjoy it at all.

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 13:51:01 -0800

Post by Eli Zaretskii
In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

People who take pleasure in being helpful to the project, and to Free
software. People who want to establish a name for themselves as a
reliable contributor. There are a lot of reasons people contribute to
Free software projects; I don't think the pursuit of authority is even
a particularly common motivation.

I know all about motivation to contribute, but I'm talking about
something slightly different.

It goes without saying that the responsibility should be taken
voluntarily, not forced upon the volunteer. But even a volunteer gets
some unique authority that is part of the job she's taken. For
example, in projects where there's a head maintainer, only that person
gets to make some decisions, and that person's agreement is needed to
do certain things. Here you have an example of a contributing
volunteer who, as part of her job, gets authority not shared by
others.

While pursuit of authority is not the most important reason people
will accept responsibility, some people do enjoy it. We shouldn't
request the volunteers to be too altruistic, I think.

[Jim Blandy]

Post by Eli Zaretskii
It goes without saying that the responsibility should be taken
voluntarily, not forced upon the volunteer. But even a volunteer gets
some unique authority that is part of the job she's taken. For
example, in projects where there's a head maintainer, only that person
gets to make some decisions, and that person's agreement is needed to
do certain things. Here you have an example of a contributing
volunteer who, as part of her job, gets authority not shared by
others.

Yes, this is what I thought you meant.

I would agree that it's unfair to give someone a responsibility
without giving them the power to carry it out. If we're doing that
here, then we're making a mistake.

But I don't think it's a good idea to grant exclusive authority as a
reward for accepting responsibility. I think contributors should earn
authority informally, through their contributions and their
participation in discussions. If you work steadily, explain yourself
well, and are easy to work with, then your words will carry weight
that no set of rules could give them. That is the sort of "position"
that we should offer our contributors to aspire to.

Official authority to make decisions should be restricted to people
who have accumulated a track record of making good ones, and being
easy to work with. Those should be the only criteria.

Setting principle aside, in practice, our current rules ---
specifically that only area maintainers may approve changes to their
areas --- make exactly the tie between responsibility and authority
that you're suggesting. And that policy is a problem spot.

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 16:34:33 -0800
I would agree that it's unfair to give someone a responsibility
without giving them the power to carry it out. If we're doing that
here, then we're making a mistake.

I most passionately agree, but I'm not sure everybody else shares our
agreement.

But I don't think it's a good idea to grant exclusive authority as a
reward for accepting responsibility. I think contributors should earn
authority informally, through their contributions and their
participation in discussions. If you work steadily, explain yourself
well, and are easy to work with, then your words will carry weight
that no set of rules could give them. That is the sort of "position"
that we should offer our contributors to aspire to.

Then why not give them the responsibility at the same time as we grant
the authority, and through the same informal process? Under the
proposed rules, nothing is lost by not having responsible maintainers,
anyway.

Official authority to make decisions should be restricted to people
who have accumulated a track record of making good ones, and being
easy to work with. Those should be the only criteria.

Until now, the criteria for granting this authority were not spelled
out, and IIRC there was never a formal discussion whether a particular
candidate satisfied those criteria. And the new rules don't propose
any formal procedure for this, either.

So we have no way of knowing whether the criteria you mention above
(to which I think I agree) are met in each individual case. For
example, some of you might think that I fail the second requirement,
of being easy to work with; and yet here I am, being responsible and
solely authorized for maintaining the GDB documentation.

Setting principle aside, in practice, our current rules ---
specifically that only area maintainers may approve changes to their
areas --- make exactly the tie between responsibility and authority
that you're suggesting. And that policy is a problem spot.

It's a different problem, though: some area maintainers are slow in
their response. When the response time is short, there are no
problems whatsoever. I think we should look for rules that improve on
the current situation without introducing new problems.

[Jim Blandy]

Post by Eli Zaretskii

Post by Jim Blandy
But I don't think it's a good idea to grant exclusive authority as a
reward for accepting responsibility. I think contributors should earn
authority informally, through their contributions and their
participation in discussions. If you work steadily, explain yourself
well, and are easy to work with, then your words will carry weight
that no set of rules could give them. That is the sort of "position"
that we should offer our contributors to aspire to.

Then why not give them the responsibility at the same time as we grant
the authority, and through the same informal process? Under the
proposed rules, nothing is lost by not having responsible maintainers,
anyway.

I don't understand this. Could you spell it out for me, as you would
for a young child?
(Sincere request, no sarcasm.)

[Eli Zaretskii]

Date: Sun, 20 Nov 2005 23:52:11 -0800

Post by Eli Zaretskii

Post by Jim Blandy
But I don't think it's a good idea to grant exclusive authority as a
reward for accepting responsibility. I think contributors should earn
authority informally, through their contributions and their
participation in discussions. If you work steadily, explain yourself
well, and are easy to work with, then your words will carry weight
that no set of rules could give them. That is the sort of "position"
that we should offer our contributors to aspire to.

Then why not give them the responsibility at the same time as we grant
the authority, and through the same informal process? Under the
proposed rules, nothing is lost by not having responsible maintainers,
anyway.

I don't understand this. Could you spell it out for me, as you would
for a young child?

Sorry for my continuing inability to explain myself. Let me try
again.

You agreed that it was unfair to give someone a responsibility without
giving them the ``power to carry it out'' (which I interpret as
authority).

Then you said (above) that authority shouldn't be given merely as a
reward for accepting responsibility, but rather earned through gradual
informal process.

To that I say, let's wait until this informal process earns the
contributor the authority, and nominate her to be a responsible
maintainer only when that happens. This could delay the nomination
considerably, or even leave us with a very small number of responsible
maintainers, but the proposed scheme works the same even in that case,
since patch commits don't require an approval from a responsible
maintainer, others have that power.

Does this make sense now?

[David Carlton]

Post by Eli Zaretskii
I'm worried that people might not want to take the responsibility
upon them if others, who don't share the responsibility, are allowed
to commit changes nonetheless.
In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

One possible way to treat this question is as an empirical one. To
that end, one could ask people currently listed in MAINTAINERS as
maintaining a given domain whether they would prefer to remain
responsible for maintaining, or merely authorized, and why. For
example, would you be interested in being responsible for djgpp and/or
documentation under the proposed new rules? If so, why?

(An answer to that question would only be the beginning of an answer
to whether the distinction is a good one, of course.)

David Carlton
***@sun.com

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 14:46:45 -0800

Post by Eli Zaretskii
In other words, if responsibility doesn't come with some unique
authority, who will want such a responsibility?

One possible way to treat this question is as an empirical one. To
that end, one could ask people currently listed in MAINTAINERS as
maintaining a given domain whether they would prefer to remain
responsible for maintaining, or merely authorized, and why. For
example, would you be interested in being responsible for djgpp and/or
documentation under the proposed new rules? If so, why?

Thanks, that was a useful thought experiment.

After thinking about this for a while, I concluded that my main
reasons for being interested in becoming a responsible maintainer is
that I'd like to influence the development and maintenance of those
specific areas according to ideas I have. For example, I might wish
to make sure the manual is well indexed: each important concept has a
@cindex entry, each command has a @kindex entry, the index entries are
well thought and easy to guess, and allow the reader to use the manual
as a reference, etc.

Now, under the suggested rules, somebody who is authorized to approve
patches to the documentation could commit changes that don't fit my
plan about indexing, without asking me, right? How can I shape the
documentation according to my ideas if I don't have the final say?
The only way would be to revert changes and/or redo them myself.
Under the current scheme, I can refuse the approval unless and until
the contributor reworks the changes according to my standards. With
that authority gone, I'm left dead in the water; doing everything
myself is not an option for me, given my chronic lack of free time,
and starting a revert war or going to the SC over disputes about
@cindex is either time-consuming or childishly silly or both.

[David Carlton]

Post by Eli Zaretskii

For example, would you be interested in being responsible for djgpp
and/or documentation under the proposed new rules? If so, why?

After thinking about this for a while, I concluded that my main
reasons for being interested in becoming a responsible maintainer is
that I'd like to influence the development and maintenance of those
specific areas according to ideas I have.

[ Indexing example snipped. ]

Post by Eli Zaretskii
Now, under the suggested rules, somebody who is authorized to approve
patches to the documentation could commit changes that don't fit my
plan about indexing, without asking me, right?

Yup.

Post by Eli Zaretskii
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,
that your suggestions are always well-considered and almost always an
improvement (no criticism implied, we're all fallible), and that in
situations where there's a disagreement, you're willing to discuss the
issue in a reasonable fashion.

So I'm pretty sure that people would continue to run documentation
patches by you in the new system. They probably won't do it quite as
consistently as they do now, but they'll do it most of the time,
especially the core GDB developers. And (correct me if I'm wrong), I
bet that, even in situations where they don't run patches by you in
advance, you'll still comment on those patches when they're committed.
And in those situations, I bet most of the time people will make the
corrections you suggest.

I don't think people will make those corrections 100% of the time; and
if somebody gets into a habit of not running doc patches by you in
advance, maybe you might get annoyed. But I'm pretty sure that you
would still have a quite significant role, indeed the primary role, in
shaping the documentation under the new system.

Of course, I could be wrong. And I'll probably go back into hiding
now, anyways. But I wanted to respond to your message, because
because I appreciate your taking my question seriously.

David Carlton
***@sun.com

[Eli Zaretskii]

Date: Tue, 22 Nov 2005 16:50:41 -0800

Post by Eli Zaretskii
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. 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?

that your suggestions are always well-considered and almost always an
improvement (no criticism implied, we're all fallible), and that in
situations where there's a disagreement, you're willing to discuss the
issue in a reasonable fashion.
So I'm pretty sure that people would continue to run documentation
patches by you in the new system. They probably won't do it quite as
consistently as they do now, but they'll do it most of the time,
especially the core GDB developers.
And (correct me if I'm wrong), I bet that, even in situations where
they don't run patches by you in advance, you'll still comment on
those patches when they're committed. And in those situations, I
bet most of the time people will make the corrections you suggest.

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. 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.

My reservations about responsibilities without an authority is not
theoretical, nor does it come out of an experience with a single
individual. (Although IMHO we shouldn't disregard Andrew's case too
quickly, because Andrew didn't quite steal his powers: he _earned_
them through many years of contributions and fruitful cooperation.
I think there's a lesson to be learned here.)

But even if we forget about that single individual, I can still 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.

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 wanted to respond to your message, because I appreciate your
taking my question seriously.

It was a very good question, so thanks for asking it. I hope our
exchange will help us find reasonable ways to overcome the
difficulties.

[Joel Brobecker]

Post by Eli Zaretskii
My reservations about responsibilities without an authority is not
theoretical,

I believe that the proposal was to give authority without responsibility.

If I understand your point well, you are asking whether we will have
people who will accept the responsibility, since they could simply
earn authority and not bind themselves with responsibility.

This is indeed an interesting question where you have to believe that
people will be willing to donate a bit of their time to help the project.
It's not completely altruistic. The reason I'm working with free software
is that it's given me so much over the past 10 years. So contributing back
is one way of working for me myself and I. I would gladly take some
responsibility (and hopefully will on the ada-* code one day) if I had
enough knowledge to do so. Take the release management role: It doesn't
give me any authority nor power. I just donate a bit of my time to
create releases when the group think is best. If tomorrow the
maintainers send a message and say: let's create a new release, I'll
just do it. I accepted the responsibility of doing this job without
any added authority.

[Eli Zaretskii]

Date: Wed, 23 Nov 2005 11:55:58 -0800

Post by Eli Zaretskii
My reservations about responsibilities without an authority is not
theoretical,

I believe that the proposal was to give authority without responsibility.

That's the same thing: if someone can have authority without
responsibility, then the one who gets responsibility doesn't get any
unique authority to go with that.

If I understand your point well, you are asking whether we will have
people who will accept the responsibility, since they could simply
earn authority and not bind themselves with responsibility.

Yes.

This is indeed an interesting question where you have to believe that
people will be willing to donate a bit of their time to help the project.

It's not only about time. It's about being responsible: that's a
burden that should not go unnoticed. The usual way to appreciate that
burden is to grant some exclusive rights. This is how any effective
organization works; if we want our small collective to be an effective
organization, we shouldn't deprive people who are willing to donate
more of some small incentive to do so.

Take the release management role: It doesn't give me any authority
nor power.

Sure, it does: no one can release GDB except you. The fact that we
didn't have a release manager is the sole most important reason why
there was no GDB release for quite some time.

If tomorrow the maintainers send a message and say: let's create a
new release, I'll just do it.

I doubt that very much. I'm sure you will see if there are any
outstanding issues, and you will ask others what they think, then make
your judgement.

[Joel Brobecker]

Post by Eli Zaretskii
That's the same thing: if someone can have authority without
responsibility, then the one who gets responsibility doesn't get any
unique authority to go with that.

What I don't understand is why this is necessary.

Post by Eli Zaretskii
It's not only about time. It's about being responsible: that's a
burden that should not go unnoticed. The usual way to appreciate that
burden is to grant some exclusive rights. This is how any effective
organization works; if we want our small collective to be an effective
organization, we shouldn't deprive people who are willing to donate
more of some small incentive to do so.

I disagree. There can be many reasons why you accept a burden.

Post by Eli Zaretskii

Take the release management role: It doesn't give me any authority
nor power.

Sure, it does: no one can release GDB except you. The fact that we
didn't have a release manager is the sole most important reason why
there was no GDB release for quite some time.

But I'm just the scribe. I translate the intent of the GDB developers
into a release when deemed appropriate by the group, not when I decide.
The scribe doesn't decide what gets written.

Post by Eli Zaretskii

If tomorrow the maintainers send a message and say: let's create a
new release, I'll just do it.

I doubt that very much. I'm sure you will see if there are any
outstanding issues, and you will ask others what they think, then make
your judgement.

This discussion is sliding a bit outside of scope towards the role of
RM. But I consider the decision of making a release a group decision.
If the group decides to make a release regardless of my objections,
I will create that release.

[Eli Zaretskii]

Date: Thu, 24 Nov 2005 09:18:14 -0800

Post by Eli Zaretskii
That's the same thing: if someone can have authority without
responsibility, then the one who gets responsibility doesn't get any
unique authority to go with that.

What I don't understand is why this is necessary.

Not necessary, preferable.

Post by Eli Zaretskii
It's not only about time. It's about being responsible: that's a
burden that should not go unnoticed. The usual way to appreciate that
burden is to grant some exclusive rights. This is how any effective
organization works; if we want our small collective to be an effective
organization, we shouldn't deprive people who are willing to donate
more of some small incentive to do so.

I disagree. There can be many reasons why you accept a burden.

In a healthy society he who accepts a burden on behalf of others
should be rewarded, even if the reward is not the most important
reason to take the burden.

Anyway, I think we made several circles around the issue, so further
discussion won't bring any new arguments. There's Daniel's
suggestion, and there's another one, supported by myself and I think
Chris, which is to allow authorized maintainers other than the RM to
kick in only after a timeout of N days. If no one objects to the
latter method too much, then we could make everybody happy; if not,
then, well, it won't be the first time I get voted down here...

[Joel Brobecker]

Post by Eli Zaretskii
In a healthy society he who accepts a burden on behalf of others
should be rewarded, even if the reward is not the most important
reason to take the burden.

I agree, but the reward is not always where you think it is.
To me, the reward has been a good free debugger.

Post by Eli Zaretskii
Anyway, I think we made several circles around the issue, so further
discussion won't bring any new arguments. There's Daniel's
suggestion, and there's another one, supported by myself and I think
Chris, which is to allow authorized maintainers other than the RM to
kick in only after a timeout of N days.

I'm fine with this approach. I think it's the polite thing to do anyway.

[Daniel Jacobowitz]

Post by Eli Zaretskii
Anyway, I think we made several circles around the issue, so further
discussion won't bring any new arguments.

I agree.

Post by Eli Zaretskii
There's Daniel's
suggestion, and there's another one, supported by myself and I think
Chris, which is to allow authorized maintainers other than the RM to
kick in only after a timeout of N days. If no one objects to the
latter method too much, then we could make everybody happy; if not,
then, well, it won't be the first time I get voted down here...

What do you consider a reasonable value for N?

I'm somewhat worried about the timeout causing friction whenever it is
used; but we can give it a try and see what results we reach.

[Christopher Faylor]

Post by Daniel Jacobowitz

Post by Eli Zaretskii
Anyway, I think we made several circles around the issue, so further
discussion won't bring any new arguments.

I agree.

Post by Eli Zaretskii
There's Daniel's
suggestion, and there's another one, supported by myself and I think
Chris, which is to allow authorized maintainers other than the RM to
kick in only after a timeout of N days. If no one objects to the
latter method too much, then we could make everybody happy; if not,
then, well, it won't be the first time I get voted down here...

What do you consider a reasonable value for N?
I'm somewhat worried about the timeout causing friction whenever it is
used; but we can give it a try and see what results we reach.

Don't you think that the lack of a timeout could cause friction, too?

You don't have to answer that. We've circled on this issue enough. :-)

How about a month for the timeout period? That won't accommodate a long
vacation but it should be enough for most scenarios.

Would adding a rider that says "Two global maintainers can agree to
apply the patch after two weeks of nonresponse" complicate things too
much? I would hate for an important patch to languish just because
someone was on vacation.

cgf

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 00:28:10 -0500
How about a month for the timeout period? That won't accommodate a long
vacation but it should be enough for most scenarios.
Would adding a rider that says "Two global maintainers can agree to
apply the patch after two weeks of nonresponse" complicate things too
much? I would hate for an important patch to languish just because
someone was on vacation.

How about if we start from something simple, like 3 weeks of timeout
and no other conditions? Then, a year or so from now, we could
analyze the results and see if we need to augment the rules.

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Fri, 25 Nov 2005 00:28:10 -0500
How about a month for the timeout period? That won't accommodate a long
vacation but it should be enough for most scenarios.
Would adding a rider that says "Two global maintainers can agree to
apply the patch after two weeks of nonresponse" complicate things too
much? I would hate for an important patch to languish just because
someone was on vacation.

How about if we start from something simple, like 3 weeks of timeout
and no other conditions? Then, a year or so from now, we could
analyze the results and see if we need to augment the rules.

You see, I was thinking a couple of days, or up to a week. I think
much longer than a week is effectively the same as not allowing
timeouts at all.

Please keep in mind that there are two very different cases: existing
maintainers who are not authorized to commit in a certain area, and
occasional or new contributors to GDB submitting a patch for review.
Do you want to be the one to explain to all the latter group "no,
sorry, we can't look at your patch for three weeks"? I've done the
"no, sorry, we need so-and-so to look at this" routine a fair number of
times in the past year, and it's no fun. With just a week, it's easy
to give the contributor feedback on the style et cetera - which often
takes a week anyway - while waiting for comments from the responsible
party.

I think such a long timeout would be a mistake. But alternatively, we
could use a long timeout and an aggressive policy for maintainers who
time out repeatedly - politely remove them from responsibility (shift
into the authorized section). How do you feel about that?

[Joel Brobecker]

Post by Daniel Jacobowitz
You see, I was thinking a couple of days, or up to a week. I think
much longer than a week is effectively the same as not allowing
timeouts at all.

I was actually thinking one week to 10 days. I like the idea of
providing feedback on simple things not area-specific such as style
while waiting for the responsible maintainer to be available.

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 09:07:12 -0800
I like the idea of providing feedback on simple things not
area-specific such as style while waiting for the responsible
maintainer to be available.

I think while waiting for the responsible maintainer, others could
provide any feedback at all, not just simple things. It's not like we
need permission from the responsible maintainer to speak up.

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 11:04:54 -0500
You see, I was thinking a couple of days, or up to a week.

Two days is awfully too few, IMO. I could think of many reasons why I
could be away of my mail for two days. Not everyone hacks GCC and GDB
for their living and have an opportunity to read gdb-patches during
office hours.

Do you want to be the one to explain to all the latter group "no,
sorry, we can't look at your patch for three weeks"?

I think there's a misunderstanding: 3 weeks was suggested as a
_timeout_, i.e. an extreme value beyond which we behave as if the
responsible maintainer were not there. It is not suggested as the
_average_ value. If, several months from now, we see that the average
delay is anywhere near 3 weeks, I will be the first one to suggest we
do something about it.

I've done the "no, sorry, we need so-and-so to look at this" routine
a fair number of times in the past year, and it's no fun.

I think in most, if not all, of those cases, the delay was much longer
than 3 weeks.

With just a week, it's easy to give the contributor feedback on the
style et cetera - which often takes a week anyway - while waiting
for comments from the responsible party.

That's another misunderstanding: there's no need for the other
maintainers to wait before they post comments about the proposed
patches, not even for a minute. They could do that right away. One
needs to wait only for the approval. Any other comments, style or
otherwise, need not wait.

In other words, the timeout is not a silence period during which no
one can say anything about the proposed patch. It's the max time we
give the responsible maintainer to review the patch and make up her
mind whether to approve it.

But alternatively, we could use a long timeout and an aggressive
policy for maintainers who time out repeatedly - politely remove
them from responsibility (shift into the authorized section). How
do you feel about that?

Responsible maintainers that time out repeatedly should be asked to
do better or to step down.

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Fri, 25 Nov 2005 11:04:54 -0500
You see, I was thinking a couple of days, or up to a week.

Two days is awfully too few, IMO. I could think of many reasons why I
could be away of my mail for two days. Not everyone hacks GCC and GDB
for their living and have an opportunity to read gdb-patches during
office hours.

I apologize. I realize this is grammatically busted usage of English,
but I've never been able to break myself of it. Here's the one I was
using:

couple
n 1: a small indefinite number; "he's coming for a couple of
days"

i.e. I meant 3-5, not two, which I agree is far too short. I'm more
than comfortable with Joel's 7-10 days, also.

[By the way, I don't generally have an opportunity to read gdb-patches
during office hours either. I do it more than I feel I ought to.]

Post by Eli Zaretskii

Do you want to be the one to explain to all the latter group "no,
sorry, we can't look at your patch for three weeks"?

I think there's a misunderstanding: 3 weeks was suggested as a
_timeout_, i.e. an extreme value beyond which we behave as if the
responsible maintainer were not there. It is not suggested as the
_average_ value. If, several months from now, we see that the average
delay is anywhere near 3 weeks, I will be the first one to suggest we
do something about it.

What are you suggesting doing with the current set of maintainers,
then? The fact remains that for most patch review, three weeks is
currently optimistic.

Post by Eli Zaretskii

With just a week, it's easy to give the contributor feedback on the
style et cetera - which often takes a week anyway - while waiting
for comments from the responsible party.

That's another misunderstanding: there's no need for the other
maintainers to wait before they post comments about the proposed
patches, not even for a minute. They could do that right away. One
needs to wait only for the approval. Any other comments, style or
otherwise, need not wait.
In other words, the timeout is not a silence period during which no
one can say anything about the proposed patch. It's the max time we
give the responsible maintainer to review the patch and make up her
mind whether to approve it.

Of course. But when the contributor asks us "OK, can it be applied
now", we have to answer "please let's wait 19 more days".

Post by Eli Zaretskii

But alternatively, we could use a long timeout and an aggressive
policy for maintainers who time out repeatedly - politely remove
them from responsibility (shift into the authorized section). How
do you feel about that?

Responsible maintainers that time out repeatedly should be asked to
do better or to step down.

Great, I agree.

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 15:43:47 -0500

Post by Eli Zaretskii

Post by Daniel Jacobowitz
Do you want to be the one to explain to all the latter group "no,
sorry, we can't look at your patch for three weeks"?

I think there's a misunderstanding: 3 weeks was suggested as a
_timeout_, i.e. an extreme value beyond which we behave as if the
responsible maintainer were not there. It is not suggested as the
_average_ value. If, several months from now, we see that the average
delay is anywhere near 3 weeks, I will be the first one to suggest we
do something about it.

What are you suggesting doing with the current set of maintainers,
then? The fact remains that for most patch review, three weeks is
currently optimistic.

If that is so, we will watch most of the current maintainers being
politely asked to step down. When the last of them goes, you can then
have your suggested approval procedure, since most areas will be left
without RMs ;-)

[Daniel Jacobowitz]

Post by Eli Zaretskii
If that is so, we will watch most of the current maintainers being
politely asked to step down. When the last of them goes, you can then
have your suggested approval procedure, since most areas will be left
without RMs ;-)

Hmm. We can manage better than that. But, let's worry about the
details of that a little later in the process, please.

We need a concrete value for N. Joel has suggested anything from a
week to ten days. I would prefer a week or less. Chris suggested a
month, you suggested three weeks in response.

Can we all reach compromise on two weeks?

[Mark Kettenis]

Date: Fri, 25 Nov 2005 16:38:49 -0500

Post by Eli Zaretskii
If that is so, we will watch most of the current maintainers being
politely asked to step down. When the last of them goes, you can then
have your suggested approval procedure, since most areas will be left
without RMs ;-)

Hmm. We can manage better than that. But, let's worry about the
details of that a little later in the process, please.
We need a concrete value for N. Joel has suggested anything from a
week to ten days. I would prefer a week or less. Chris suggested a
month, you suggested three weeks in response.
Can we all reach compromise on two weeks?

I've not contributed much to this discussion. For one thing I've not
had too much time over the past two weeks to actively participate, and
the time I had, I spent on writing code and fixing bugs. I really
think that at most we need a set of guidelines; not a set of spelt out
rules. I let the time I wait for approval depend on several factors:
when my change is complex, invasive, etc. I'll probably wait months
before I'll commit the patch without explicit approval. If the patch
is borderline obvious, I'll usually ask for objections and commit if I
don't see any within a few days. I'll also check whether I see any
posts from the responsible maintainer on the list. If he/she is
usually very active, but not posting to the list for a while, I'll
just wait until he/she is back again. I think in general this works
pretty well, and if for some reason a particular maintainer expresses
his/her unhappiness with my action I try to change my behaviour. I
think that's the way we should interact with each other.

Yes we had problems in the recent past with a particular maintainer.
But I still think the other maintainers (including myself) are partly
to blame for that situation. Trust between maintainers was broken,
but you're not going to restore that trust by formulating some strict
rules.

Mark

[Daniel Jacobowitz]

Post by Mark Kettenis
I've not contributed much to this discussion. For one thing I've not
had too much time over the past two weeks to actively participate, and
the time I had, I spent on writing code and fixing bugs. I really
think that at most we need a set of guidelines; not a set of spelt out
when my change is complex, invasive, etc. I'll probably wait months
before I'll commit the patch without explicit approval. If the patch
is borderline obvious, I'll usually ask for objections and commit if I
don't see any within a few days. I'll also check whether I see any
posts from the responsible maintainer on the list. If he/she is
usually very active, but not posting to the list for a while, I'll
just wait until he/she is back again. I think in general this works
pretty well, and if for some reason a particular maintainer expresses
his/her unhappiness with my action I try to change my behaviour. I
think that's the way we should interact with each other.

I think that's the most effective way to get things done _at present_.
But at present, not much does get done.

The problem is that it's very touchy-feely. You have to have a mental
profile of what every maintainer wants. You have to constantly worry
about stepping on someone's toes. You have to be willing to wait -
sometimes for a very long time - to fix bugs in "other people's code".

The common parts of GDB, the parts where we do currently have (mostly
busy or inactive) maintainers... and the wide-reaching interfaces that
it hurts to even touch... they're terribly out of date. I strongly
believe that GDB needs to evolve if it wants to stay relevant. I'm
trying to create an environment where:

- The people who are interested in improving GDB can do so.
- New contributors don't find posting GDB patches to be a futile
and frustrating (sometimes baffling) experience. Which they
currently do. I've spoken with plenty of contributors who
felt this way in the last two years.
- Consequently contributors to GDB are more likely to stay around
for the long term, help GDB grow, and share the maintenance
burden.

Post by Mark Kettenis
Yes we had problems in the recent past with a particular maintainer.
But I still think the other maintainers (including myself) are partly
to blame for that situation. Trust between maintainers was broken,
but you're not going to restore that trust by formulating some strict
rules.

The situation I presume you're talking about is not the problem I'm
trying to solve.

[Eli Zaretskii]

Date: Sat, 26 Nov 2005 00:03:40 +0100 (CET)
I really think that at most we need a set of guidelines; not a set
of spelt out rules.

What would be those guidelines, specifically? I presume, if we go
that way, those guidelines do need to be spelled out somewhere, yes?

In any case, it would seem to me that we've already been there in this
discussion: the idea that being nice and cooperative will solve the
problems. At least some of us don't believe that this method is good
enough in practice.

Yes we had problems in the recent past with a particular maintainer.
But I still think the other maintainers (including myself) are partly
to blame for that situation.

Acknowledging the blame is important, but it does not in itself
produce a promise that this won't happen again.

Trust between maintainers was broken, but you're not going to
restore that trust by formulating some strict rules.

I think following rules is a good way of restoring trust. What would
you suggest in its stead? (We've discussed this issue as well, so you
may wish to re-read those parts of the thread.)

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 16:38:49 -0500
Can we all reach compromise on two weeks?

I'm not happy with two weeks because I myself didn't finish a review
in two weeks several times.

If my proposal, for immediate (i.e. less than a week) reaction that
acknowledges the RFA and states the ETA, is okay with you, would you
mind to extend the timeout? Chris said he likes this idea.

Or, alternatively, we could have a very short timeout, like your
``couple of days'', not for the review itself, but for the initial
reaction of the maintainer; the time frame for the review could then
be negotiated between the contributor, the RM, and the rest of the
maintainers.

If we cannot find any compromise along the above-mentioned guidelines,
I will reluctantly agree to the 2-week timeout.

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Fri, 25 Nov 2005 16:38:49 -0500
Can we all reach compromise on two weeks?

I'm not happy with two weeks because I myself didn't finish a review
in two weeks several times.
If my proposal, for immediate (i.e. less than a week) reaction that
acknowledges the RFA and states the ETA, is okay with you, would you
mind to extend the timeout? Chris said he likes this idea.

Yes, I like this - in fact, that's what I was planning to use in my
next revision of the proposal (which I didn't find time for today after
all).

I never wanted a promise that the review of anything would be
_finished_ within the timeout; I realize I may have been unclear about
that. I did want it to _start_, however - feedback on the patch from
someone who could approve or reject it, even if they did neither.

Having a week ACK and a month for the actual review is fine with me.
It meets my primary goal: clear signs of progress, or a clear path
forward if no signs of progress are seen. And I still mean "the start
of the review", within that month.

Post by Eli Zaretskii
If we cannot find any compromise along the above-mentioned guidelines,
I will reluctantly agree to the 2-week timeout.

It's my goal to find something that we're all minimally reluctant about
:-)

[Eli Zaretskii]

Date: Thu, 24 Nov 2005 22:06:05 -0500
I'm somewhat worried about the timeout causing friction whenever it is
used

I'm not sure I understand what you mean by ``friction''. Can you
elaborate?

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Thu, 24 Nov 2005 22:06:05 -0500
I'm somewhat worried about the timeout causing friction whenever it is
used

I'm not sure I understand what you mean by ``friction''. Can you
elaborate?

I expect that contributors will get annoyed at maintainers who are
responsible but inactive (because they've added delay), and in return
those maintainers will get annoyed at contributors for any comments
they make about the subject.

A timeout is all well and good for you and for documentation, Eli;
you're unbelievably responsive. Surely you've noticed that you're just
about the _only_ area reviewer who is so responsive. We also need to
consider everybody else.

I'd rather not continue this discussion, though; I think we need to
compromise and move on.

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 10:57:43 -0500

Post by Eli Zaretskii
I'm not sure I understand what you mean by ``friction''. Can you
elaborate?

I expect that contributors will get annoyed at maintainers who are
responsible but inactive (because they've added delay), and in return
those maintainers will get annoyed at contributors for any comments
they make about the subject.

We could ask that maintainers immediately acknowledge seeing the RFA,
and tell the contributor the ETA for their review. I think this will
avoid annoyances in many cases: people usually get annoyed that they
don't see any response whatsoever, not because they need to wait for a
few days.

A timeout is all well and good for you and for documentation, Eli;
you're unbelievably responsive.

Only for the documentation; when I need to review code, e.g. in
breakpoint.c, it usually takes a few days, as I don't have enough free
time on weekdays to wade through non-trivial code.

I think we need to compromise and move on.

Yep.

[Christopher Faylor]

Post by Eli Zaretskii

Date: Fri, 25 Nov 2005 10:57:43 -0500
From: Daniel Jacobowitz

Post by Eli Zaretskii
I'm not sure I understand what you mean by ``friction''. Can you
elaborate?

I expect that contributors will get annoyed at maintainers who are
responsible but inactive (because they've added delay), and in return
those maintainers will get annoyed at contributors for any comments
they make about the subject.

We could ask that maintainers immediately acknowledge seeing the RFA,
and tell the contributor the ETA for their review. I think this will
avoid annoyances in many cases: people usually get annoyed that they
don't see any response whatsoever, not because they need to wait for a
few days.

I think this is a good idea. I was trying to err in the direction of
being overcautious before but I'm comfortable with making the timeout
smaller, too. How about if an area maintainer hasn't responded, in some
way, to email within a week, the patch is open for a general maintainer
to apply?

Isn't it reasonable to assume that an area maintainer should be reading
gdb-patches on at least a weekly frequency, assuming that they are not
out-of-town? If they do this, then they should be able to at least send
a "can't review now - will get to this in N days" type of message. If
they don't respond to a message then presumably they are not available
at all.

I guess you could complicate this with more rules about what to do when
a maintainer responds but doesn't deliver but I don't think we need to
go there for now.

cgf

[Eli Zaretskii]

Date: Fri, 25 Nov 2005 19:03:05 -0500
How about if an area maintainer hasn't responded, in some way, to
email within a week, the patch is open for a general maintainer to
apply?

I'm okay with this, assuming that ``some response'' could be as simple
as ``RFA acknowledged, will review it in a week or so''.

Isn't it reasonable to assume that an area maintainer should be reading
gdb-patches on at least a weekly frequency, assuming that they are not
out-of-town?

It's reasonable.

I guess you could complicate this with more rules about what to do when
a maintainer responds but doesn't deliver but I don't think we need to
go there for now.

No, we don't need to go there before we see this actually happening.

[Daniel Jacobowitz]

Post by Eli Zaretskii

Date: Fri, 25 Nov 2005 19:03:05 -0500
How about if an area maintainer hasn't responded, in some way, to
email within a week, the patch is open for a general maintainer to
apply?

I'm okay with this, assuming that ``some response'' could be as simple
as ``RFA acknowledged, will review it in a week or so''.

OK.

I'm going to plan to review this discussion (including a dozen or so
messages that I've only skimmed so far) later today, and update the
draft as best I can. I have the feeling there was another unresolved
issue, but I'm not sure what it was.

[Christopher Faylor]

Post by Eli Zaretskii
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've been lurking on this discussion (except for the highly fruitful
discussion about whether maintainers should be cc'ed) but I have to say
that Eli summarizes my concerns above.

As has been mentioned, the gcc project has similar rules and I've
occasionally had the experience of having things checked into
cygwin/windows-specific sections of gcc without my approval. The
changes are ones that I agree with but it is still disconcerting.

I've got a little more vested in gdb than I do in gcc so I'm likely to
be a little less happy about changes to my area of maintenance and I
worry about people accepting changes which seem to make sense but do not
take into account concerns that I may have with my more thorough
understanding of windows.

I guess, in short, I'm concerned about well-meaning global maintainers
who don't know what they don't know making changes that will cause me
some work later. I don't relish the idea of arguing with someone about
a change that they have just approved.

So, I think I'd be more comfortable with some sort of timeout on patch
review such that a global reviewer will only apply a patch if it has
gone unreviewed by an area maintainer after N days. However, if
something like that is not acceptable, then I will just adapt.

cgf

[Eli Zaretskii]

Date: Wed, 23 Nov 2005 15:13:37 -0500
So, I think I'd be more comfortable with some sort of timeout on patch
review such that a global reviewer will only apply a patch if it has
gone unreviewed by an area maintainer after N days.

I suggested something like this somewhere in the course of this
discussion; I hope it didn't get lost in the dispute. So I also am in
favor of such an arrangement.

[David Carlton]

Post by Eli Zaretskii

Date: Tue, 22 Nov 2005 16:50:41 -0800

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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.)

...

Post by Eli Zaretskii
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.)

Post by Eli Zaretskii
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.

...

Post by Eli Zaretskii
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!)

Post by Eli Zaretskii
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
***@sun.com

[Eli Zaretskii]

Date: Wed, 23 Nov 2005 12:40:59 -0800

Post by Eli Zaretskii
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.

Documentation was just an example, let's not read too much into it.
What I really meant is code, since we are all programmers and thus
care much more about code than about docs.

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.

If we designate people who deserve that, why not? Are you saying that
you dislike or don't believe in leadership as a matter of principle?

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!)

Well, right: we must generalize it, otherwise every example will not
teach us anything about the general issue.

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?

These both boil down to not having anyone responsible. I don't think
we should go as far as that.

[Daniel Jacobowitz]

Post by Ian Lance Taylor

Date: Fri, 18 Nov 2005 10:26:18 -0500
I don't think the words are at all similar in semantic meaning.
Responsibility is an obligation and authority is a privilege.

What I meant was that the expression of their meaning is similar: it's
who reviews patches, right?

I'm not sure what you mean, but I think that I do understand what
Daniel means.

Thanks for the alternative explanation, Ian!

Eli, if this helps, here's another sort of example: someone who has
done a lot of work in an area, and who we trust to make changes to that
area without review, might be listed as "authorized to commit". But
that person may either be uninterested in reviewing other people's
changes (unfortunate; I'm not sure how I'd feel about this case in
practice), not very good at reviewing other people's changes, or simply
always too busy to review other people's changes. So listing them as
the responsible maintainer would do a disservice to the rest of the
community.

In an ideal world, none of those would ever happen. In ours I expect
they happen frequently.

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 10:26:18 -0500
I don't think the words are at all similar in semantic meaning.
Responsibility is an obligation and authority is a privilege.

What I meant was that the expression of their meaning is similar: it's
who reviews patches, right?

This would be easier with Venn diagrams, but they don't lend themselves
to email very well. Let me give some examples. Afterwards, I will
attempt to clarify the original descriptions, if these help.

Sorry, I must be too dumb today. In the example you've given, who has
the ``authority for reviewing patches''?

Post by Eli Zaretskii
Isn't it desirable to have an expert for each area of GDB code? If
not, why not? what are the disadvantages of that? (I don't think this
is directly related to the present discussion, but I was too surprised
to read your negative response to Joel's question to let that go
without understanding it.)

Perhaps we're just using "goal" differently.

Probably. Thanks for explaining what you meant.

[Eli Zaretskii]

Date: Wed, 16 Nov 2005 23:48:01 -0500

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

Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers. Final authority
resides with the GDB Steering Committee.

Does this mean any addition to the list of recognized maintainers must
be brought before the committee for the final approval?

Responsible Maintainers
These are active developers who have agreed to review patches to particular
areas of GDB, in which they have particular knowledge and experience. The
areas are expected to be broad; multiple maintainers responsible for an area
may wish to informally subdivide the area further to improve review.
*LIST*

The current list of responsibilities need to be carefully redone, for
this to be effective (you say something similar in the comments, see
below).

Separating responsibility for patch review from authority for patch review
is a new concept for GDB; I believe the suggestion was Ian's.

This separation is not at all clear from the text. I needed to go
back and reread it after reading this comment, but even upon second
reading I'm still not sure what the text really says. Whose
responsibility is it to review patches and who has the authority for
patch review, according to your proposal?

So I think the text should be made more explicit on this; perhaps
simply mention and explain this separation instead of leaving it for
the reader to deduce.

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.

The problem is, trust is built by following rules which are initially
intentionally restrictive. As the trust grows, the restrictions can
be gradually lifted.

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 would like for every defined "area" of approval to be fairly well defined,
possibly a specific list of files.

Yes.

This does not replace the entire explanatory text of the MAINTAINERS file of
course. Bits like the Obvious Fix rule or the bits about Joel's role as RM
would remain. I've just covered the section highlights.

It would be better to post diffs against the current MAINTAINERS.
Then no one will need to guess what parts are being replaced and which
aren't.

Thanks for working on this, anyway.

[Jim Blandy]

Post by Eli Zaretskii

Post by Daniel Jacobowitz
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.

The problem is, trust is built by following rules which are initially
intentionally restrictive. As the trust grows, the restrictions can
be gradually lifted.

That's not the pattern I'm familiar with. An organization can have
strict rules, and as trust is built up, people will tolerate those
rules being bent or set aside in specific cases. But I've never seen
the restrictions be explicitly lifted as a result of that. We have
restrictions in place that many of GDB's contributors don't like, and
which are definitely hampering progress.

Post by Eli Zaretskii
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?

You need to be more specific. I agree with your characterization that
we trusted too much in 1999 that everything would just work out, but I
don't see that this proposal makes the same mistake. What particular
passages concern you? What are their consequences?

[Eli Zaretskii]

Date: Thu, 17 Nov 2005 13:10:21 -0800

Post by Eli Zaretskii
The problem is, trust is built by following rules which are initially
intentionally restrictive. As the trust grows, the restrictions can
be gradually lifted.

That's not the pattern I'm familiar with. An organization can have
strict rules, and as trust is built up, people will tolerate those
rules being bent or set aside in specific cases. But I've never seen
the restrictions be explicitly lifted as a result of that.

I don't see any significant difference between these two patterns. If
and when people tolerate rule-bending, we might as well codify that.

We have restrictions in place that many of GDB's contributors don't
like, and which are definitely hampering progress.

You are generalizing what I said in a way that wasn't in my intent. I
wasn't arguing for more restrictions, I was arguing for codified
self-restraint where we were burnt in the past.

Post by Eli Zaretskii
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?

You need to be more specific. I agree with your characterization that
we trusted too much in 1999 that everything would just work out, but I
don't see that this proposal makes the same mistake. What particular
passages concern you?

The comment by Daniel that his suggestions, and specifically the power
to commit without an RFA, implicitly assume trust.

What are their consequences?

Bad blood and, eventually, deep mistrust. We've been there, I'm sure
you remember that.

Daniel says that if we don't trust each other, we should ``work on
trust''. But how do we ``work on trust''? do we all go to a shrink
together once a week? The only way I know of to work on trust is by
building it as we cooperate in the development and maintenance of GDB.
And while trust is in construction, it might be a good idea to take
some voluntary restraint upon ourselves.

[Joel Brobecker]

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

Overall, I like the proposal.

Post by Daniel Jacobowitz
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.

Post by Daniel Jacobowitz
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.

Post by Daniel Jacobowitz
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.

Post by Daniel Jacobowitz
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).

Post by Daniel Jacobowitz
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.

Post by Daniel Jacobowitz
(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.

[Eli Zaretskii]

Date: Thu, 17 Nov 2005 15:10:20 -0800
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.

How far into the past does your history go? I've seen unsolvable
disagreements less than a year ago.

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.

I thought we wanted to minimize SC involvement. If that's true, we
should try to actively avoid situations where we need to go to the SC,
not simply assume they will happen seldom enough to be insignificant.

One problem with going to the SC is that their procedures take a lot
of time. See how much time it took to resolve the last feud we had.
I think we don't want the adverse effect the SC's slow judgement has
on GDB development.

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.

What ``waste of time''? It normally takes a few day--a week, say--to
wait for objections, comments, etc. We could limit that period to
something reasonable, like 10 days. We could do any number of other
things to prevent the delay from getting unreasonably long. What I
cannot understand is why people are arguing for DOING NOTHING AT ALL.

How many developers have been bulies in GDB in the past 5 years?

One thing I've learned about risk management is that you need to
consider the damage caused in case an event actually happens, not only
the probability of the event. Some events are so damaging that you
might take extreme measures to make sure they never happen again.

Let's not penalize the "nice guys", the majority of you, and deal with
the few "bad guys" when the situation demands it.

I hate to lecture, but let me remind you that laws were invented
because leaving rules of conduct to the people, assuming they are
reasonable and fair, was found to not work.

More to the point, if the ``penalty'' is reasonably tolerable, I don't
understand why we cannot ``penalize'' ourselves a bit, if in return we
regain trust and cooperation.

Let me say this in another way: This community, good-willing as
it may be, failed a serious test of its ability to cooperate just a
few months ago! Isn't it reasonable to step back a bit and practice
self-restraint for a while, until we have more than a few months of
good cooperation behind us?

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.

That's not what happened last time. Experience should teach us that
such situations tend to create much uglier dynamics than the idyllic
picture you envision. Somehow, that experience taught us nothing, or
so it seems.

Or maybe it's the old man in me talking, I don't know.

Post by Eli Zaretskii
(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.

Since Daniel sets up his mailer to prevent replies getting to him by
direct email, I find it ironic, to say the least, that he forces us to
get the same message twice.

[Daniel Jacobowitz]

Post by Eli Zaretskii
Since Daniel sets up his mailer to prevent replies getting to him by
direct email,

Huh?

Post by Eli Zaretskii
I find it ironic, to say the least, that he forces us to
get the same message twice.

If you feel "forced" or offended, I will make a note never to CC you
and a list again. I was trying to make sure I reached everybody, since
they don't all read the lists. I'm sorry you found my attempt to be
helpful to be annoying instead.

(Need to think about the trimmed bits some more before I reply to
them.)

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 10:05:37 -0500

Post by Eli Zaretskii
Since Daniel sets up his mailer to prevent replies getting to him by
direct email,

Huh?

I mean the Mail-Followup-To header. Remember that conversation we had
in private about it?

Post by Eli Zaretskii
I find it ironic, to say the least, that he forces us to
get the same message twice.

If you feel "forced" or offended, I will make a note never to CC you
and a list again.

I'm sorry my innocent remark causes such over-reaction. All I did was
ask a question. I put it in parentheses to show that it's neither
very important nor directly relevant to the main discussion. Then
people asked me why I said that, and I explained. No offense intended
or taken.

I'm sorry you found my attempt to be helpful to be annoying instead.

I said ``ironic'', not annoying.

[Paul Gilliam]

Post by Eli Zaretskii

Date: Thu, 17 Nov 2005 15:10:20 -0800
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.

How far into the past does your history go? I've seen unsolvable
disagreements less than a year ago.

Do you have a URL into the mailing list archive?

Post by Eli Zaretskii

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.

I thought we wanted to minimize SC involvement. If that's true, we
should try to actively avoid situations where we need to go to the SC,
not simply assume they will happen seldom enough to be insignificant.
One problem with going to the SC is that their procedures take a lot
of time. See how much time it took to resolve the last feud we had.

Do you have a URL into the mailing list archive?

Post by Eli Zaretskii
I think we don't want the adverse effect the SC's slow judgement has
on GDB development.

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.

What ``waste of time''? It normally takes a few day--a week, say--to
wait for objections, comments, etc. We could limit that period to
something reasonable, like 10 days. We could do any number of other
things to prevent the delay from getting unreasonably long. What I
cannot understand is why people are arguing for DOING NOTHING AT ALL.

How many developers have been bulies in GDB in the past 5 years?

One thing I've learned about risk management is that you need to

This sounds like "the voice of authority". Could you tell us your bona fides?

Post by Eli Zaretskii
consider the damage caused in case an event actually happens, not only
the probability of the event. Some events are so damaging that you
might take extreme measures to make sure they never happen again.

Let's not penalize the "nice guys", the majority of you, and deal with
the few "bad guys" when the situation demands it.

I hate to lecture, but let me remind you that laws were invented
because leaving rules of conduct to the people, assuming they are
reasonable and fair, was found to not work.
More to the point, if the ``penalty'' is reasonably tolerable, I don't
understand why we cannot ``penalize'' ourselves a bit, if in return we
regain trust and cooperation.
Let me say this in another way: This community, good-willing as
it may be, failed a serious test of its ability to cooperate just a
few months ago! Isn't it reasonable to step back a bit and practice
self-restraint for a while, until we have more than a few months of
good cooperation behind us?

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.

That's not what happened last time. Experience should teach us that

Do you have a URL into the mailing list archive?

Post by Eli Zaretskii
such situations tend to create much uglier dynamics than the idyllic
picture you envision. Somehow, that experience taught us nothing, or
so it seems.
Or maybe it's the old man in me talking, I don't know.

Post by Eli Zaretskii
(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.

Since Daniel sets up his mailer to prevent replies getting to him by
direct email, I find it ironic, to say the least, that he forces us to
get the same message twice.

Is there a technological solution to this problem? Something that could
tell if a person were NOT subscribed to the list and send the mail directly?

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 09:56:14 -0800

Post by Eli Zaretskii

Date: Thu, 17 Nov 2005 15:10:20 -0800
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.

How far into the past does your history go? I've seen unsolvable
disagreements less than a year ago.

Do you have a URL into the mailing list archive?

I started to look for it, but then I read your other comments and
realized that you were mocking me. So I won't bother looking for the
relevant messages. Some of them were in private mail, so there's no
URLs anyway.

But reality doesn't change if there's no URL to show as evidence. If
you don't believe me that these things happened, ask others here, they
will tell you.

Is there a technological solution to this problem? Something that could
tell if a person were NOT subscribed to the list and send the mail directly?

I don't know of any technological solution, except to configure the
list server to filter addresses in order to prevent multiple messages.
Most mailing lists don't do that, and FWIW I'm used to have double
messages, they don't annoy me. That's why I cannot understand why
people bother to use Mail-Followup-To. IMHO it causes more trouble
than it's worth.

[Paul Gilliam]

Post by Eli Zaretskii

Date: Fri, 18 Nov 2005 09:56:14 -0800

Post by Eli Zaretskii

Date: Thu, 17 Nov 2005 15:10:20 -0800
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.

How far into the past does your history go? I've seen unsolvable
disagreements less than a year ago.

Do you have a URL into the mailing list archive?

I started to look for it, but then I read your other comments and
realized that you were mocking me. So I won't bother looking for the

Please forgive me if I gave the impression I was mocking you! That was far from my intention!
I just wanted to be able to take a look at the situation to which you where refering.

Post by Eli Zaretskii
relevant messages. Some of them were in private mail, so there's no
URLs anyway.
But reality doesn't change if there's no URL to show as evidence. If
you don't believe me that these things happened, ask others here, they
will tell you.

I was not calling your veracity into question, I just don't remember. Sometimes I get so focused
on the current thing, I tend to tune-out what doesn't directly apply to it.

Post by Eli Zaretskii

Is there a technological solution to this problem? Something that could
tell if a person were NOT subscribed to the list and send the mail directly?

I don't know of any technological solution, except to configure the
list server to filter addresses in order to prevent multiple messages.
Most mailing lists don't do that, and FWIW I'm used to have double
messages, they don't annoy me.

Me too. It took awhile to get used to, though.

Post by Eli Zaretskii
That's why I cannot understand why
people bother to use Mail-Followup-To. IMHO it causes more trouble
than it's worth.

PS: You have contributed so much to GDB that only a jerk would be less than polite to you.

[Joel Brobecker]

Post by Eli Zaretskii
I don't know of any technological solution, except to configure the
list server to filter addresses in order to prevent multiple messages.
Most mailing lists don't do that, and FWIW I'm used to have double
messages, they don't annoy me. That's why I cannot understand why
people bother to use Mail-Followup-To. IMHO it causes more trouble
than it's worth.

I was going to answer Eli privately about this, but maybe it's going
to be useful to others too, so here is a small suggestion. You know
that emails all have a message ID that is unique to the email. The same
email sent to a mailing list and an individual will have the same
message ID. So you can use that to filter out doubles. Here is a
procmail recipe that does just that:

# The following 2 rules will avoid e-mail duplicates (these duplicates
# are stored in the duplicates folder instead).
:0Wch:.messageid.lock
| formail -D 32768 .messageid.cache

:0a:
duplicates

[Christopher Faylor]

Post by Eli Zaretskii

Post by Paul Gilliam
Is there a technological solution to this problem? Something that could
tell if a person were NOT subscribed to the list and send the mail directly?

I don't know of any technological solution, except to configure the
list server to filter addresses in order to prevent multiple messages.
Most mailing lists don't do that, and FWIW I'm used to have double
messages, they don't annoy me. That's why I cannot understand why
people bother to use Mail-Followup-To. IMHO it causes more trouble
than it's worth.

Dunno if it helps but, coincidentally enough, I've transitioned this
list to using a feature of the mailing list software which adds a
"X-IsSubscribed: yes" to the header of a message if the sender was
subscribed.

This isn't foolproof since it just does a raw lookup of the senders
email address in the subscriber database and could be fooled by extra
"stuff" in an email address but if do you see the field, you can be
sure that the person who sent the message is subscribed.

cgf

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 21:44:55 -0500
Dunno if it helps but, coincidentally enough, I've transitioned this
list to using a feature of the mailing list software which adds a
"X-IsSubscribed: yes" to the header of a message if the sender was
subscribed.

Thanks, I will look into programming Emacs to use this header.

Do you happen to know whether this header is used by other mailing
lists? That is, are we talking about a solution that's private to
this list, or is it more general than that? This is important for the
decision how to add this option to Emacs.

[Christopher Faylor]

Post by Eli Zaretskii

Date: Fri, 18 Nov 2005 21:44:55 -0500
From: Christopher Faylor
Dunno if it helps but, coincidentally enough, I've transitioned this
list to using a feature of the mailing list software which adds a
"X-IsSubscribed: yes" to the header of a message if the sender was
subscribed.

Thanks, I will look into programming Emacs to use this header.
Do you happen to know whether this header is used by other mailing
lists? That is, are we talking about a solution that's private to
this list, or is it more general than that? This is important for the
decision how to add this option to Emacs.

As far as I know, this is only used on sourceware.org mailing lists.
It's something that I added. It was kind of tricky to inject this
using the mailing list software that we use on the system but it
is something that I always wanted.

cgf

[Eli Zaretskii]

Date: Sat, 19 Nov 2005 12:04:58 -0500

Post by Eli Zaretskii

Date: Fri, 18 Nov 2005 21:44:55 -0500
From: Christopher Faylor
Dunno if it helps but, coincidentally enough, I've transitioned this
list to using a feature of the mailing list software which adds a
"X-IsSubscribed: yes" to the header of a message if the sender was
subscribed.

Thanks, I will look into programming Emacs to use this header.
Do you happen to know whether this header is used by other mailing
lists? That is, are we talking about a solution that's private to
this list, or is it more general than that? This is important for the
decision how to add this option to Emacs.

As far as I know, this is only used on sourceware.org mailing lists.
It's something that I added. It was kind of tricky to inject this
using the mailing list software that we use on the system but it
is something that I always wanted.

Unfortunately, it doesn't seem to work. For example, the message I'm
replying to came without the X-IsSubscribed header, although I'm quite
sure you are a subscriber. I did see that header on a message I sent
myself; is it possible that you only arranged for this header on the
message reflected back to the sender?

[Christopher Faylor]

Post by Eli Zaretskii
Unfortunately, it doesn't seem to work. For example, the message I'm
replying to came without the X-IsSubscribed header, although I'm quite
sure you are a subscriber. I did see that header on a message I sent
myself; is it possible that you only arranged for this header on the
message reflected back to the sender?

That's what I meant by saying that this method not foolproof. My sender
address does not match my subscription address.

Again, this is not a foolproof way of figuring out if someone is not
subscribed but it should be a foolproof way of figuring out if someone
is subscribed, i.e., if you see the header then the sender is definitely
subscribed. If you don't see the header then the person may or may not
be subscribed, depending on how they sent the software.

That said, however, I just modified the software to check the header from
as well as the envelope sender. Maybe this email will show up with the
X-IsSubscribed header set.

cgf

[Christopher Faylor]

Post by Christopher Faylor

Post by Eli Zaretskii
Unfortunately, it doesn't seem to work. For example, the message I'm
replying to came without the X-IsSubscribed header, although I'm quite
sure you are a subscriber. I did see that header on a message I sent
myself; is it possible that you only arranged for this header on the
message reflected back to the sender?

That's what I meant by saying that this method not foolproof. My sender
address does not match my subscription address.
Again, this is not a foolproof way of figuring out if someone is not
subscribed but it should be a foolproof way of figuring out if someone
is subscribed, i.e., if you see the header then the sender is definitely
subscribed. If you don't see the header then the person may or may not
be subscribed, depending on how they sent the software.
That said, however, I just modified the software to check the header from
as well as the envelope sender. Maybe this email will show up with the
X-IsSubscribed header set.

Nope. Oh well.

cgf

[Christopher Faylor]

Post by Christopher Faylor

Post by Christopher Faylor

Post by Eli Zaretskii
Unfortunately, it doesn't seem to work. For example, the message I'm
replying to came without the X-IsSubscribed header, although I'm quite
sure you are a subscriber. I did see that header on a message I sent
myself; is it possible that you only arranged for this header on the
message reflected back to the sender?

That's what I meant by saying that this method not foolproof. My sender
address does not match my subscription address.
Again, this is not a foolproof way of figuring out if someone is not
subscribed but it should be a foolproof way of figuring out if someone
is subscribed, i.e., if you see the header then the sender is definitely
subscribed. If you don't see the header then the person may or may not
be subscribed, depending on how they sent the software.
That said, however, I just modified the software to check the header from
as well as the envelope sender. Maybe this email will show up with the
X-IsSubscribed header set.

Nope. Oh well.

That's better.

cgf

[Eli Zaretskii]

Date: Sat, 19 Nov 2005 17:25:05 -0500

Post by Christopher Faylor

Post by Christopher Faylor
That said, however, I just modified the software to check the header from
as well as the envelope sender. Maybe this email will show up with the
X-IsSubscribed header set.

Nope. Oh well.

That's better.

Yep. Thanks!

[Eli Zaretskii]

Date: Sat, 19 Nov 2005 17:21:30 -0500
Again, this is not a foolproof way of figuring out if someone is not
subscribed but it should be a foolproof way of figuring out if someone
is subscribed, i.e., if you see the header then the sender is definitely
subscribed. If you don't see the header then the person may or may not
be subscribed, depending on how they sent the software.

Well, if a large fraction of subscribers don't get this header, it's
not very useful.

That said, however, I just modified the software to check the header from
as well as the envelope sender. Maybe this email will show up with the
X-IsSubscribed header set.

Hope this will now catch most of the guilty parties ;-)

[Joel Brobecker]

Post by Eli Zaretskii
Well, if a large fraction of subscribers don't get this header, it's
not very useful.

I actually find this feature anti-productive for messages addressed
to me. Keep me in the list of recipients when you answer a message
from me, please!

[Eli Zaretskii]

Date: Sat, 19 Nov 2005 21:28:06 -0800

Post by Eli Zaretskii
Well, if a large fraction of subscribers don't get this header, it's
not very useful.

I actually find this feature anti-productive for messages addressed
to me. Keep me in the list of recipients when you answer a message
from me, please!

Sigh... it seems there's no way to keep everybody happy wrt this.

[Christopher Faylor]

Post by Eli Zaretskii

Date: Sat, 19 Nov 2005 21:28:06 -0800
From: Joel Brobecker

Post by Eli Zaretskii
Well, if a large fraction of subscribers don't get this header, it's
not very useful.

I actually find this feature anti-productive for messages addressed
to me. Keep me in the list of recipients when you answer a message
from me, please!

Sigh... it seems there's no way to keep everybody happy wrt this.

Yeah. I guess different people use mailing lists in different ways but
it surely seems like the lowest common denominator of just sending a
message to the list should be adequate for any maintainer and especially
for a GDB Release Manager.

cgf

[Daniel Jacobowitz]

Post by Christopher Faylor

Post by Eli Zaretskii

Date: Sat, 19 Nov 2005 21:28:06 -0800
From: Joel Brobecker

Post by Eli Zaretskii
Well, if a large fraction of subscribers don't get this header, it's
not very useful.

I actually find this feature anti-productive for messages addressed
to me. Keep me in the list of recipients when you answer a message
from me, please!

Sigh... it seems there's no way to keep everybody happy wrt this.

Yeah. I guess different people use mailing lists in different ways but
it surely seems like the lowest common denominator of just sending a
message to the list should be adequate for any maintainer and especially
for a GDB Release Manager.

Can we please continue this fascinating discussion of mailing list
etiquette in a separate thread, preferably without the sniping?

He didn't say he didn't read the list, merely that he found being CC'd
an effective way to get his attention.

[Joel Brobecker]

Eli,

I understand your position, and the rationale behind it. I still
think that the addition of rules as you suggest will be causing
extra work and delays. I won't argue much more about this, since
the overhead will hopefully be small. This remains to be verified.

It does seem however that one particular individual caused you to
lose the trust you had in all the other maintainers, and that is
very unfortunate. Otherwise, why would you insist on adding an
overhead that essentially allows us to restrain a maintainer.
Giving your trust, and letting them commit without approval does
not prevent monitoring of your peers' work, nor does it prevent
you from commenting and helping improve his work.

The situation in GDB has, in my opinion, changed a great deal in
the past year. For one thing, the SC committee is now more organized,
and able to make decisions. My opinion is that we should avoid
going to the SC if we can deal ourselves with a situation. This
is what I mean by "reduce the use of the SC as much as possible".
However, we should not hesitate to go to them should we need to.
That's what they are here for.

I prefer not to draw any parallel between society (laws) and our group
(rules). Our group (the group of maintainers) is by invitation only. One
has to demonstrate that one is able to work cooperatively with the rest
of the maintainers before he gets nominated. I still deeply belive that
all of us are good natured and willing to listen to the others, just as
much as I'm trying to listen to you. I believe that abusive behavior
will not happen overnight, and that the threat of losing one's
priviledges by SC decision will be enough to prevent abuse repeats.
Cf the GCC maintainer story I told in my previous message.

I listened to your arguments, I understand where they come from. But
I think you are asking for unnecessary measures. I've exposed my
arguments as best as I could. Hopefully you understood my arguments
and the group is able to make the decision that will benefit the project
the most.

Also, it just occurred to me that this discussion is only a small part
of the overal discussion. The rest of the discussion seemed much more
important to me: The distinction between reponsibility (who promised
to review), and the authority (who has the priviledge).

[Eli Zaretskii]

Date: Fri, 18 Nov 2005 11:50:40 -0800
I won't argue much more about this

Neither will I. As long as my opinion is understood, you are free to
do whatever you wish with it.

In the comments below, I will try to clarify my opinion without adding
any new arguments.

It does seem however that one particular individual caused you to
lose the trust you had in all the other maintainers

It wasn't a single individual. And I didn't lose trust in all the
other maintainers as the result; if I somehow implied that, I'm sorry.

What I lost is the optimistic belief in our ability to resolve such
situations based on good will.

Otherwise, why would you insist on adding an overhead that
essentially allows us to restrain a maintainer.

I didn't insist, but I thought (and still think) that some
self-imposed restraint will do us good.

Giving your trust, and letting them commit without approval does
not prevent monitoring of your peers' work, nor does it prevent
you from commenting and helping improve his work.

I have on my memory examples of my comments and requests being
disregarded or met with silence. So being able to comment (this is a
public list, after all!) is not sufficient.

Hopefully you understood my arguments and the group is able to make
the decision that will benefit the project the most.

Actually, it is unclear to me how we will make the decision here. Do
we vote? do we go to the SC and ask them to pass judgement?

The rest of the discussion seemed much more important to me: The
distinction between reponsibility (who promised to review), and the
authority (who has the priviledge).

I responded to this elsewhere in this thread.

[Mark Kettenis]

Date: Wed, 16 Nov 2005 23:48:01 -0500
So, first some proposed text, and then some additional rationale. Please,
let the list know your opinions.
Working With Other Maintainers
All maintainers are encouraged to post major patches to gdb-patches for
comments, even if they have the authority to commit the patch without
review. This especially includes patches which change internal interfaces
(e.g. global functions, data structures) or external interfaces (e.g. user,
remote, MI, et cetera).

I like this formulation.

Global Maintainers
The global maintainers may review and commit any change to GDB. For major
changes, or changes to areas with other active developers, global
maintainers are encouraged to post patches for comment and review before
committing.
The global maintainers are responsible for reviewing patches to any area
for which no one else is listed as responsible.
In case of abuse, e.g. committing patches without approval or patches which
go against an agreed-upon and documented roadmap for GDB, global maintainers
have the authority to revert _any_ applied patch. No one may reapply a
reverted patch without either persuading the reverter, or bringing the issue
to the GDB Steering Committee for discussion.
(NOTE: documentation links to roadmap items would be good here; we don't
have any today but we could at least create a placeholder in gdbint.texi for
them. Alternatively, we could use a freeform Wiki for this; that seems to
work well for other projects... END NOTE.)

I think gdbint.texi should document what is implemented, and not what
will be implemented. A Wiki seems to be a more appropriate place for
roadmap items. They can be moved to gdbint.texi when they've been
implemented.

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.

Interesting idea.

Changes to the List of Maintainers
Most changes (especially additions) to the list of recognized maintainers
are handled by consensus among the global maintainers. Final authority
resides with the GDB Steering Committee.

Is everybody currently on the "Write After Approval" list considered
to be a Maintainer? If so, I don't hope adding someone to that list
will require explicit permision from the SC.

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.

Fair enough.

The biggest advantage I see in the split is a very clear image of who to
pester about pending patches, which does not necessarily include every GDB
developer who wants to be able to work in that area.

That's probably a good idea. Right now we have quite a number of
vacua, i.e. areas where it is not clear who to pester. In some cases
that's because no one is listed, in others someone is listed who
hasn't show any recent activity.

I would like for every defined "area" of approval to be fairly well defined,
possibly a specific list of files. I believe it's reasonable to include
most changes to users of an interface under the umbrella of approval which
covers the implementation of the interface, so files which include
maintained headers would be somewhat under the authority of the maintainers
involved. This may need to be clarified.

Do we consider it a as a goal to have someone listed for every "area"
(file?) in gdb?

Mark

[David Carlton]

Post by Daniel Jacobowitz
I have put together one possible alternative, drawing heavily on
comments from Ian, Jim, and Andrew on the steering committee list
last year. Obviously I like my own proposal or I wouldn't be
sharing it :-) But I want to know what everyone else involved
thinks!

I certainly don't qualify as involved any more, but I feel like
chiming in anyways.

In general, I heartily approve of this proposal; on a personal level,
I think that it would have improved both my happiness and productivity
as a GDB contributor in the past.

In particular, I think that allowing global maintainers to approve and
commit everywhere is long overdue; I also think that separating
responsibility for reviewing from authorization for reviewing is a
very good idea.

I'm not sure GDB is quite big enough for the entire proposed ecosystem
to work, but I think it's worth a try. I'm curious what the
proportion of Responsible Maintainers to Authorized Committers in a
given area will be; I'm also curious whether there will be enough
(even any?) Patch Champions. But when I say "curious", I mean just
that: let's try it and find out.

Most importantly, it seems like the proposal might help grow the GDB
ecosystem. Somebody starting to work on GDB (and with free time on
their hands, a student or something) might decide, after a little bit,
to take on the role of Patch Champion; after proving herself, she
might become an Authorized Commiter in one area, and then eventually
give up her Patch Champion roles in order to spend time as an actual
Responsible Maintainer. So there's a nice possible ramp-up, where
people can be trusted more and take on more responsibilities gradually
over time. And, equally important, shed responsibilities as outside
commitments impinge, without feeling that she is letting down
everybody else.

David Carlton
***@sun.com

[Michael Snyder]

I sincerely hope to forward the discussion toward, rather than
away from convergence. These are casual suggestions; if anyone
thinks they're too daft, I'll happily withdraw them.

1) Unique approval authority.

How about this -- if there's to be a specific maintainer with
sole approval authority for certain areas, there'll have to be
a list of them somewhere: presumably in the MAINTAINERS file
or equivalent.

What if each such area maintainer has the right to spell out
his or her own policy as far as "timeouts", etc.? Rather than
forcing a one-size-fits-all policy? Eg.:

Area Maintainers:
gdb/doc: Eli Zaretskii.
Checkin policy: "I prefer that any changes other
than obvious fixes await my explicit approval for
at least 3 weeks".
mumble mumble: Daniel Jacobowitz
Checkin policy: "If I haven't responded within
3-5 days, any global maintainer may approve."

2) Reverting a patch

There hasn't been too much discussion of this, but it
makes me nervous. May I throw this out on the table?
How about if, except for area maintainers, it requires
the agreement of at least two maintainers to revert
another maintainer's patch?

To be perfectly clear, that means that if someone
checks in a docs patch that Eli doesn't like, Eli
can yank it out immediately, but other than Eli it
would require a motion and a second.

[Eli Zaretskii]

Date: Sat, 26 Nov 2005 20:30:11 -0800
What if each such area maintainer has the right to spell out
his or her own policy as far as "timeouts", etc.? Rather than
forcing a one-size-fits-all policy?

I'm not sure this is needed, but I have no objections to adding this.

2) Reverting a patch
There hasn't been too much discussion of this, but it
makes me nervous. May I throw this out on the table?
How about if, except for area maintainers, it requires
the agreement of at least two maintainers to revert
another maintainer's patch?

I'd prefer it the other way around: a patch can be reverted if it (the
patch) does not have anyone to support it except whoever committed it.

To be perfectly clear, that means that if someone
checks in a docs patch that Eli doesn't like, Eli
can yank it out immediately, but other than Eli it
would require a motion and a second.

it means that I can revert the patch if no one else thinks it should
stay.

[Ian Lance Taylor]

Post by Michael Snyder
2) Reverting a patch
There hasn't been too much discussion of this, but it
makes me nervous. May I throw this out on the table?
How about if, except for area maintainers, it requires
the agreement of at least two maintainers to revert
another maintainer's patch?

For comparison, a gcc patch which causes a testsuite or significant
performance regression on a primary target may be reverted, if any two
people with write privileges (i.e., not just maintainers, but also
write-after-approval) agree, after waiting for 48 hours. In practice
this is rarely actually done; the threat of it is normally enough to
resolve the situation one way or another.

Ian

[Eli Zaretskii]

Date: 26 Nov 2005 20:59:40 -0800
For comparison, a gcc patch which causes a testsuite or significant
performance regression on a primary target may be reverted, if any two
people with write privileges (i.e., not just maintainers, but also
write-after-approval) agree, after waiting for 48 hours. In practice
this is rarely actually done; the threat of it is normally enough to
resolve the situation one way or another.

Thanks for the info.

However, our problem was what to do when a patch does not cause
failures in the testsuite, but still causes objections.

[Christopher Faylor]

Post by Michael Snyder
I sincerely hope to forward the discussion toward, rather than
away from convergence. These are casual suggestions; if anyone
thinks they're too daft, I'll happily withdraw them.
1) Unique approval authority.
How about this -- if there's to be a specific maintainer with
sole approval authority for certain areas, there'll have to be
a list of them somewhere: presumably in the MAINTAINERS file
or equivalent.
What if each such area maintainer has the right to spell out
his or her own policy as far as "timeouts", etc.? Rather than
gdb/doc: Eli Zaretskii.
Checkin policy: "I prefer that any changes other
than obvious fixes await my explicit approval for
at least 3 weeks".
mumble mumble: Daniel Jacobowitz
Checkin policy: "If I haven't responded within
3-5 days, any global maintainer may approve."

I don't like this much. I'd rather that there was just one rule that we
could all (as Daniel says) reluctantly agree on. I think it will be
pretty confusing to contributors otherwise.

"Yes, I can apply your changes to inflow.c but I can't apply your
changes to win32-nat.c since cgf is unavailable and his rules dictate
that I can't apply your patch since you submitted it on the third Friday
of a month with an 'r' in it."

Not to keep bringing this up, but this reminds me of the "please Cc me
when you send email to the mailing list" requirements. If you have to
take extra effort to figure out how to do a common operation the you are
putting impediments in the flow of communication. I don't think that's
ever a good thing.

cgf