This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Maintainer policy for GDB
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...]
On Thu, Nov 17, 2005 at 10:14:46PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 17 Nov 2005 09:03:54 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > 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.
On Thu, Nov 17, 2005 at 10:12:08PM +0200, Eli Zaretskii wrote:
> (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.
> > 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.
> > 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.
> > 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.
> > 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.
> 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.
On Thu, Nov 17, 2005 at 03:10:20PM -0800, Joel Brobecker wrote:
> > 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.
> > 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.
> > 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.
On Fri, Nov 18, 2005 at 12:52:19AM +0100, Mark Kettenis wrote:
> > (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?
> > 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?
> > 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.
> > 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.]
--
Daniel Jacobowitz
CodeSourcery, LLC