* Maintainer policy for GDB @ 2005-11-17 4:48 Daniel Jacobowitz [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> ` (4 more replies) 0 siblings, 5 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-17 4:48 UTC (permalink / raw) To: gdb Cc: Jim Blandy, Kevin Buettner, Andrew Cagney, J.T. Conklin, Fred Fish, Mark Kettenis, Peter Schauer, Stan Shebs, Michael Snyder, Eli Zaretskii, Elena Zannoni 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
[parent not found: <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com>]
* Fwd: Maintainer policy for GDB [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> @ 2005-11-17 6:44 ` Jim Blandy 2005-11-17 14:04 ` Daniel Jacobowitz 2005-11-17 20:16 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Jim Blandy @ 2005-11-17 6:44 UTC (permalink / raw) To: gdb [sourceware.org blocked my message because it had too many recipients.] ---------- Forwarded message ---------- From: Jim Blandy <jimb@red-bean.com> Date: Nov 16, 2005 10:40 PM Subject: Re: Maintainer policy for GDB To: gdb@sourceware.org, Jim Blandy <jimb@redhat.com>, Kevin Buettner <kevinb@redhat.com>, Andrew Cagney <cagney@gnu.org>, "J.T. Conklin" <jtc@acorntoolworks.com>, Fred Fish <fnf@ninemoons.com>, Mark Kettenis <kettenis@gnu.org>, Peter Schauer <Peter.Schauer@regent.e-technik.tu-muenchen.de>, Stan Shebs <shebs@apple.com>, Michael Snyder <msnyder@redhat.com>, Eli Zaretskii <eliz@gnu.org>, Elena Zannoni <ezannoni@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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fwd: Maintainer policy for GDB 2005-11-17 6:44 ` Fwd: " Jim Blandy @ 2005-11-17 14:04 ` Daniel Jacobowitz 2005-11-17 17:07 ` Jim Blandy 2005-11-17 20:15 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-17 14:04 UTC (permalink / raw) To: gdb On Wed, Nov 16, 2005 at 10:44:26PM -0800, Jim Blandy wrote: > [sourceware.org blocked my message because it had too many recipients.] Weird, worked for me... > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fwd: Maintainer policy for GDB 2005-11-17 14:04 ` Daniel Jacobowitz @ 2005-11-17 17:07 ` Jim Blandy 2005-11-17 20:38 ` Jim Blandy 2005-11-17 20:15 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Jim Blandy @ 2005-11-17 17:07 UTC (permalink / raw) To: gdb On 11/17/05, Daniel Jacobowitz <drow@false.org> wrote: > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fwd: Maintainer policy for GDB 2005-11-17 17:07 ` Jim Blandy @ 2005-11-17 20:38 ` Jim Blandy 0 siblings, 0 replies; 101+ messages in thread From: Jim Blandy @ 2005-11-17 20:38 UTC (permalink / raw) To: gdb On 11/17/05, Jim Blandy <jimb@red-bean.com> wrote: > On 11/17/05, Daniel Jacobowitz <drow@false.org> wrote: > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fwd: Maintainer policy for GDB 2005-11-17 14:04 ` Daniel Jacobowitz 2005-11-17 17:07 ` Jim Blandy @ 2005-11-17 20:15 ` Eli Zaretskii 1 sibling, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-17 20:15 UTC (permalink / raw) To: gdb > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> 2005-11-17 6:44 ` Fwd: " Jim Blandy @ 2005-11-17 20:16 ` Eli Zaretskii 1 sibling, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-17 20:16 UTC (permalink / raw) To: Jim Blandy Cc: gdb, kevinb, cagney, jtc, fnf, kettenis, Peter.Schauer, shebs, msnyder, ezannoni > Date: Wed, 16 Nov 2005 22:40:56 -0800 > From: Jim Blandy <jimb@red-bean.com> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 4:48 Maintainer policy for GDB Daniel Jacobowitz [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> @ 2005-11-17 20:14 ` Eli Zaretskii 2005-11-17 21:10 ` Jim Blandy 2005-11-17 23:10 ` Joel Brobecker ` (2 subsequent siblings) 4 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-17 20:14 UTC (permalink / raw) To: gdb Cc: Jim Blandy, Kevin Buettner, Andrew Cagney, J.T. Conklin, Fred Fish, Mark Kettenis, Peter Schauer, Stan Shebs, Michael Snyder, Elena Zannoni > Date: Wed, 16 Nov 2005 23:48:01 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: Jim Blandy <jimb@redhat.com>, Kevin Buettner <kevinb@redhat.com>, > Andrew Cagney <cagney@gnu.org>, > "J.T. Conklin" <jtc@acorntoolworks.com>, > Fred Fish <fnf@ninemoons.com>, Mark Kettenis <kettenis@gnu.org>, > Peter Schauer <Peter.Schauer@regent.e-technik.tu-muenchen.de>, > Stan Shebs <shebs@apple.com>, Michael Snyder <msnyder@redhat.com>, > Eli Zaretskii <eliz@gnu.org>, Elena Zannoni <ezannoni@redhat.com> (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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 20:14 ` Eli Zaretskii @ 2005-11-17 21:10 ` Jim Blandy 2005-11-18 3:07 ` Daniel Jacobowitz 2005-11-18 12:14 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Jim Blandy @ 2005-11-17 21:10 UTC (permalink / raw) To: Eli Zaretskii Cc: gdb, Andrew Cagney, J.T. Conklin, Fred Fish, Peter Schauer, Elena Zannoni [I've dropped individuals from the CC list that I know to read gdb@ regularly.] On 11/17/05, Eli Zaretskii <eliz@gnu.org> wrote: > > 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. > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 21:10 ` Jim Blandy @ 2005-11-18 3:07 ` Daniel Jacobowitz 2005-11-18 3:26 ` Joel Brobecker ` (2 more replies) 2005-11-18 12:14 ` Eli Zaretskii 1 sibling, 3 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 3:07 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:07 ` Daniel Jacobowitz @ 2005-11-18 3:26 ` Joel Brobecker 2005-11-18 3:30 ` Daniel Jacobowitz 2005-11-18 11:09 ` Andrew STUBBS 2005-11-18 13:15 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-18 3:26 UTC (permalink / raw) To: gdb > > 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? -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:26 ` Joel Brobecker @ 2005-11-18 3:30 ` Daniel Jacobowitz 2005-11-18 3:33 ` Joel Brobecker 2005-11-18 3:46 ` Wu Zhou 0 siblings, 2 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 3:30 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb On Thu, Nov 17, 2005 at 07:26:44PM -0800, Joel Brobecker wrote: > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:30 ` Daniel Jacobowitz @ 2005-11-18 3:33 ` Joel Brobecker 2005-11-18 3:46 ` Wu Zhou 1 sibling, 0 replies; 101+ messages in thread From: Joel Brobecker @ 2005-11-18 3:33 UTC (permalink / raw) To: gdb > > 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.... -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:30 ` Daniel Jacobowitz 2005-11-18 3:33 ` Joel Brobecker @ 2005-11-18 3:46 ` Wu Zhou 1 sibling, 0 replies; 101+ messages in thread From: Wu Zhou @ 2005-11-18 3:46 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Joel Brobecker, gdb On Thu, 17 Nov 2005, Daniel Jacobowitz wrote: > On Thu, Nov 17, 2005 at 07:26:44PM -0800, Joel Brobecker wrote: > > > > 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:07 ` Daniel Jacobowitz 2005-11-18 3:26 ` Joel Brobecker @ 2005-11-18 11:09 ` Andrew STUBBS 2005-11-18 11:46 ` Eli Zaretskii 2005-11-18 13:15 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: Andrew STUBBS @ 2005-11-18 11:09 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb Daniel Jacobowitz wrote: >>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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 11:09 ` Andrew STUBBS @ 2005-11-18 11:46 ` Eli Zaretskii 2005-11-18 11:59 ` Andrew STUBBS 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 11:46 UTC (permalink / raw) To: Andrew STUBBS; +Cc: drow, gdb > Date: Fri, 18 Nov 2005 11:04:54 +0000 > From: Andrew STUBBS <andrew.stubbs@st.com> > Cc: gdb@sourceware.org > > 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''? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 11:46 ` Eli Zaretskii @ 2005-11-18 11:59 ` Andrew STUBBS 0 siblings, 0 replies; 101+ messages in thread From: Andrew STUBBS @ 2005-11-18 11:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: drow, gdb Eli Zaretskii wrote: >>Date: Fri, 18 Nov 2005 11:04:54 +0000 >>From: Andrew STUBBS <andrew.stubbs@st.com> >>Cc: gdb@sourceware.org >> >>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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 3:07 ` Daniel Jacobowitz 2005-11-18 3:26 ` Joel Brobecker 2005-11-18 11:09 ` Andrew STUBBS @ 2005-11-18 13:15 ` Eli Zaretskii 2005-11-18 15:26 ` Daniel Jacobowitz 2 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 13:15 UTC (permalink / raw) To: gdb > Date: Thu, 17 Nov 2005 22:07:11 -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. 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. > > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 13:15 ` Eli Zaretskii @ 2005-11-18 15:26 ` Daniel Jacobowitz 2005-11-18 18:24 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 15:26 UTC (permalink / raw) To: gdb On Fri, Nov 18, 2005 at 03:14:56PM +0200, Eli Zaretskii wrote: > > 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. > > 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. > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 15:26 ` Daniel Jacobowitz @ 2005-11-18 18:24 ` Eli Zaretskii 2005-11-18 18:44 ` Ian Lance Taylor 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 18:24 UTC (permalink / raw) To: gdb > Date: Fri, 18 Nov 2005 10:26:18 -0500 > From: Daniel Jacobowitz <drow@false.org> > > 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''? > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:24 ` Eli Zaretskii @ 2005-11-18 18:44 ` Ian Lance Taylor 2005-11-18 18:51 ` Daniel Jacobowitz 2005-11-18 21:09 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Ian Lance Taylor @ 2005-11-18 18:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb Eli Zaretskii <eliz@gnu.org> writes: > > Date: Fri, 18 Nov 2005 10:26:18 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > > > 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:44 ` Ian Lance Taylor @ 2005-11-18 18:51 ` Daniel Jacobowitz 2005-11-18 21:40 ` Eli Zaretskii 2005-11-18 21:09 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 18:51 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Eli Zaretskii, gdb On Fri, Nov 18, 2005 at 10:44:05AM -0800, Ian Lance Taylor wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > > > Date: Fri, 18 Nov 2005 10:26:18 -0500 > > > From: Daniel Jacobowitz <drow@false.org> > > > > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:51 ` Daniel Jacobowitz @ 2005-11-18 21:40 ` Eli Zaretskii 2005-11-18 21:46 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 21:40 UTC (permalink / raw) To: Ian Lance Taylor, gdb > Date: Fri, 18 Nov 2005 13:51:35 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org > > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:40 ` Eli Zaretskii @ 2005-11-18 21:46 ` Daniel Jacobowitz 2005-11-18 22:33 ` Eli Zaretskii 2005-11-18 21:51 ` Jim Blandy 2005-11-18 22:46 ` David Carlton 2 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 21:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ian Lance Taylor, gdb On Fri, Nov 18, 2005 at 11:40:40PM +0200, Eli Zaretskii wrote: > > Date: Fri, 18 Nov 2005 13:51:35 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org > > > > 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 CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:46 ` Daniel Jacobowitz @ 2005-11-18 22:33 ` Eli Zaretskii 2005-11-18 22:41 ` Daniel Jacobowitz 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 22:33 UTC (permalink / raw) To: gdb > Date: Fri, 18 Nov 2005 16:46:20 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: Ian Lance Taylor <ian@airs.com>, gdb@sourceware.org > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 22:33 ` Eli Zaretskii @ 2005-11-18 22:41 ` Daniel Jacobowitz 2005-11-19 9:34 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 22:41 UTC (permalink / raw) To: gdb On Sat, Nov 19, 2005 at 12:33:38AM +0200, Eli Zaretskii wrote: > > Date: Fri, 18 Nov 2005 16:46:20 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > Cc: Ian Lance Taylor <ian@airs.com>, gdb@sourceware.org > > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 22:41 ` Daniel Jacobowitz @ 2005-11-19 9:34 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 9:34 UTC (permalink / raw) To: gdb > Date: Fri, 18 Nov 2005 17:41:38 -0500 > From: Daniel Jacobowitz <drow@false.org> > > On Sat, Nov 19, 2005 at 12:33:38AM +0200, Eli Zaretskii wrote: > > > Date: Fri, 18 Nov 2005 16:46:20 -0500 > > > From: Daniel Jacobowitz <drow@false.org> > > > Cc: Ian Lance Taylor <ian@airs.com>, gdb@sourceware.org > > > > > > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:40 ` Eli Zaretskii 2005-11-18 21:46 ` Daniel Jacobowitz @ 2005-11-18 21:51 ` Jim Blandy 2005-11-18 22:29 ` Eli Zaretskii 2005-11-18 22:46 ` David Carlton 2 siblings, 1 reply; 101+ messages in thread From: Jim Blandy @ 2005-11-18 21:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ian Lance Taylor, gdb On 11/18/05, Eli Zaretskii <eliz@gnu.org> wrote: > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:51 ` Jim Blandy @ 2005-11-18 22:29 ` Eli Zaretskii 2005-11-19 0:34 ` Jim Blandy 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 22:29 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb > Date: Fri, 18 Nov 2005 13:51:01 -0800 > From: Jim Blandy <jimb@red-bean.com> > Cc: Ian Lance Taylor <ian@airs.com>, gdb@sourceware.org > > On 11/18/05, Eli Zaretskii <eliz@gnu.org> wrote: > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 22:29 ` Eli Zaretskii @ 2005-11-19 0:34 ` Jim Blandy 2005-11-19 10:54 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Jim Blandy @ 2005-11-19 0:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On 11/18/05, Eli Zaretskii <eliz@gnu.org> wrote: > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 0:34 ` Jim Blandy @ 2005-11-19 10:54 ` Eli Zaretskii 2005-11-21 7:52 ` Jim Blandy 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 10:54 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb > Date: Fri, 18 Nov 2005 16:34:33 -0800 > From: Jim Blandy <jimb@red-bean.com> > Cc: gdb@sourceware.org > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 10:54 ` Eli Zaretskii @ 2005-11-21 7:52 ` Jim Blandy 2005-11-21 22:35 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Jim Blandy @ 2005-11-21 7:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On 11/19/05, Eli Zaretskii <eliz@gnu.org> wrote: > > From: Jim Blandy <jimb@red-bean.com> > > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-21 7:52 ` Jim Blandy @ 2005-11-21 22:35 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-21 22:35 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb > Date: Sun, 20 Nov 2005 23:52:11 -0800 > From: Jim Blandy <jimb@red-bean.com> > Cc: gdb@sourceware.org > > On 11/19/05, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Jim Blandy <jimb@red-bean.com> > > > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:40 ` Eli Zaretskii 2005-11-18 21:46 ` Daniel Jacobowitz 2005-11-18 21:51 ` Jim Blandy @ 2005-11-18 22:46 ` David Carlton 2005-11-19 10:38 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: David Carlton @ 2005-11-18 22:46 UTC (permalink / raw) To: gdb On Fri, 18 Nov 2005 23:40:40 +0200, Eli Zaretskii <eliz@gnu.org> said: > 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 david.carlton@sun.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 22:46 ` David Carlton @ 2005-11-19 10:38 ` Eli Zaretskii 2005-11-23 1:28 ` David Carlton 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 10:38 UTC (permalink / raw) To: David Carlton; +Cc: gdb > From: David Carlton <david.carlton@sun.com> > Date: Fri, 18 Nov 2005 14:46:45 -0800 > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 10:38 ` Eli Zaretskii @ 2005-11-23 1:28 ` David Carlton 2005-11-23 19:56 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: David Carlton @ 2005-11-23 1:28 UTC (permalink / raw) To: gdb; +Cc: David Carlton On Sat, 19 Nov 2005 12:37:54 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: David Carlton <david.carlton@sun.com> >> 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. ] > 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. > 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 david.carlton@sun.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 1:28 ` David Carlton @ 2005-11-23 19:56 ` Eli Zaretskii 2005-11-23 20:13 ` Joel Brobecker ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-23 19:56 UTC (permalink / raw) To: David Carlton; +Cc: gdb > Cc: David Carlton <David.Carlton@sun.com> > From: David Carlton <david.carlton@sun.com> > Date: Tue, 22 Nov 2005 16:50:41 -0800 > > > How can I shape the documentation according to my ideas if I don't > > have the final say? > > By acting exactly the way you do now. Anybody paying attention to GDB > development knows that you're a very fast and responsive reviewer But you see, this ``fast response'' argument works both ways: if I'm a fast reviewer, why should it matter that only I can approve documentation changes--a few hours of delay cannot possibly hurt anyone or anything. 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 19:56 ` Eli Zaretskii @ 2005-11-23 20:13 ` Joel Brobecker 2005-11-24 4:51 ` Eli Zaretskii 2005-11-23 20:41 ` Christopher Faylor 2005-11-24 2:05 ` David Carlton 2 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-23 20:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Carlton, gdb > 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. -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 20:13 ` Joel Brobecker @ 2005-11-24 4:51 ` Eli Zaretskii 2005-11-24 20:36 ` Joel Brobecker 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-24 4:51 UTC (permalink / raw) To: Joel Brobecker; +Cc: david.carlton, gdb > Date: Wed, 23 Nov 2005 11:55:58 -0800 > From: Joel Brobecker <brobecker@adacore.com> > Cc: David Carlton <david.carlton@sun.com>, gdb@sourceware.org > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-24 4:51 ` Eli Zaretskii @ 2005-11-24 20:36 ` Joel Brobecker 2005-11-24 20:47 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-24 20:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: david.carlton, gdb > 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. > 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. > > 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. > > 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. -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-24 20:36 ` Joel Brobecker @ 2005-11-24 20:47 ` Eli Zaretskii 2005-11-24 21:20 ` Joel Brobecker 2005-11-25 3:07 ` Daniel Jacobowitz 0 siblings, 2 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-24 20:47 UTC (permalink / raw) To: Joel Brobecker; +Cc: david.carlton, gdb > Date: Thu, 24 Nov 2005 09:18:14 -0800 > From: Joel Brobecker <brobecker@adacore.com> > Cc: david.carlton@sun.com, gdb@sourceware.org > > > 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. > > 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... ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-24 20:47 ` Eli Zaretskii @ 2005-11-24 21:20 ` Joel Brobecker 2005-11-25 3:07 ` Daniel Jacobowitz 1 sibling, 0 replies; 101+ messages in thread From: Joel Brobecker @ 2005-11-24 21:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: david.carlton, gdb > 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. > 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. -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-24 20:47 ` Eli Zaretskii 2005-11-24 21:20 ` Joel Brobecker @ 2005-11-25 3:07 ` Daniel Jacobowitz 2005-11-25 8:36 ` Christopher Faylor 2005-11-25 9:23 ` Eli Zaretskii 1 sibling, 2 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-25 3:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Joel Brobecker, david.carlton, gdb On Thu, Nov 24, 2005 at 10:36:44PM +0200, Eli Zaretskii wrote: > Anyway, I think we made several circles around the issue, so further > discussion won't bring any new arguments. I agree. > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 3:07 ` Daniel Jacobowitz @ 2005-11-25 8:36 ` Christopher Faylor 2005-11-25 8:37 ` Eli Zaretskii 2005-11-25 9:23 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-25 8:36 UTC (permalink / raw) To: gdb On Thu, Nov 24, 2005 at 10:06:05PM -0500, Daniel Jacobowitz wrote: >On Thu, Nov 24, 2005 at 10:36:44PM +0200, Eli Zaretskii wrote: >> Anyway, I think we made several circles around the issue, so further >> discussion won't bring any new arguments. > >I agree. > >> 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 8:36 ` Christopher Faylor @ 2005-11-25 8:37 ` Eli Zaretskii 2005-11-25 17:07 ` Daniel Jacobowitz 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 8:37 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 00:28:10 -0500 > From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 8:37 ` Eli Zaretskii @ 2005-11-25 17:07 ` Daniel Jacobowitz 2005-11-25 19:53 ` Joel Brobecker 2005-11-25 20:10 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-25 17:07 UTC (permalink / raw) To: gdb On Fri, Nov 25, 2005 at 10:36:05AM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Nov 2005 00:28:10 -0500 > > From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> > > > > 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? -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 17:07 ` Daniel Jacobowitz @ 2005-11-25 19:53 ` Joel Brobecker 2005-11-25 20:43 ` Eli Zaretskii 2005-11-25 20:10 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-25 19:53 UTC (permalink / raw) To: gdb > 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. -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 19:53 ` Joel Brobecker @ 2005-11-25 20:43 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 20:43 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb > Date: Fri, 25 Nov 2005 09:07:12 -0800 > From: Joel Brobecker <brobecker@adacore.com> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 17:07 ` Daniel Jacobowitz 2005-11-25 19:53 ` Joel Brobecker @ 2005-11-25 20:10 ` Eli Zaretskii 2005-11-25 21:03 ` Daniel Jacobowitz 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 20:10 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 11:04:54 -0500 > From: Daniel Jacobowitz <drow@false.org> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 20:10 ` Eli Zaretskii @ 2005-11-25 21:03 ` Daniel Jacobowitz 2005-11-25 21:38 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-25 21:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On Fri, Nov 25, 2005 at 10:08:31PM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Nov 2005 11:04:54 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > > > 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.] > > 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. > > 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". > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 21:03 ` Daniel Jacobowitz @ 2005-11-25 21:38 ` Eli Zaretskii 2005-11-25 23:04 ` Daniel Jacobowitz 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 21:38 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 15:43:47 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: gdb@sourceware.org > > > > 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 ;-) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 21:38 ` Eli Zaretskii @ 2005-11-25 23:04 ` Daniel Jacobowitz 2005-11-25 23:42 ` Mark Kettenis 2005-11-26 9:31 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-25 23:04 UTC (permalink / raw) To: gdb On Fri, Nov 25, 2005 at 11:02:49PM +0200, Eli Zaretskii wrote: > 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? -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 23:04 ` Daniel Jacobowitz @ 2005-11-25 23:42 ` Mark Kettenis 2005-11-26 0:03 ` Daniel Jacobowitz 2005-11-26 9:38 ` Eli Zaretskii 2005-11-26 9:31 ` Eli Zaretskii 1 sibling, 2 replies; 101+ messages in thread From: Mark Kettenis @ 2005-11-25 23:42 UTC (permalink / raw) To: drow; +Cc: gdb > Date: Fri, 25 Nov 2005 16:38:49 -0500 > From: Daniel Jacobowitz <drow@false.org> > > On Fri, Nov 25, 2005 at 11:02:49PM +0200, Eli Zaretskii wrote: > > 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 23:42 ` Mark Kettenis @ 2005-11-26 0:03 ` Daniel Jacobowitz 2005-11-26 9:38 ` Eli Zaretskii 1 sibling, 0 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-26 0:03 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb On Sat, Nov 26, 2005 at 12:03:40AM +0100, Mark Kettenis wrote: > 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. 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. > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 23:42 ` Mark Kettenis 2005-11-26 0:03 ` Daniel Jacobowitz @ 2005-11-26 9:38 ` Eli Zaretskii 1 sibling, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-26 9:38 UTC (permalink / raw) To: Mark Kettenis; +Cc: drow, gdb > Date: Sat, 26 Nov 2005 00:03:40 +0100 (CET) > From: Mark Kettenis <mark.kettenis@xs4all.nl> > CC: gdb@sourceware.org > > 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.) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 23:04 ` Daniel Jacobowitz 2005-11-25 23:42 ` Mark Kettenis @ 2005-11-26 9:31 ` Eli Zaretskii 2005-11-27 15:07 ` Daniel Jacobowitz 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-26 9:31 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 16:38:49 -0500 > From: Daniel Jacobowitz <drow@false.org> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-26 9:31 ` Eli Zaretskii @ 2005-11-27 15:07 ` Daniel Jacobowitz 2005-11-28 8:51 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-27 15:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On Sat, Nov 26, 2005 at 11:23:11AM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Nov 2005 16:38:49 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > > > 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. > 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 :-) -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-27 15:07 ` Daniel Jacobowitz @ 2005-11-28 8:51 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-28 8:51 UTC (permalink / raw) To: gdb > Date: Sun, 27 Nov 2005 00:00:14 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: gdb@sourceware.org > > 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. Then we are very close to an agreement. Could you perhaps post a revised wording for MAINTAINERS, based on the discussions until now? > It's my goal to find something that we're all minimally reluctant about > :-) And everybody else's, I presume. Thanks. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 3:07 ` Daniel Jacobowitz 2005-11-25 8:36 ` Christopher Faylor @ 2005-11-25 9:23 ` Eli Zaretskii 2005-11-25 16:04 ` Daniel Jacobowitz 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 9:23 UTC (permalink / raw) To: gdb > Date: Thu, 24 Nov 2005 22:06:05 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: Joel Brobecker <brobecker@adacore.com>, david.carlton@sun.com, > gdb@sourceware.org > > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 9:23 ` Eli Zaretskii @ 2005-11-25 16:04 ` Daniel Jacobowitz 2005-11-25 20:08 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-25 16:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb On Fri, Nov 25, 2005 at 10:36:59AM +0200, Eli Zaretskii wrote: > > Date: Thu, 24 Nov 2005 22:06:05 -0500 > > From: Daniel Jacobowitz <drow@false.org> > > Cc: Joel Brobecker <brobecker@adacore.com>, david.carlton@sun.com, > > gdb@sourceware.org > > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 16:04 ` Daniel Jacobowitz @ 2005-11-25 20:08 ` Eli Zaretskii 2005-11-26 7:28 ` Christopher Faylor 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-25 20:08 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 10:57:43 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: gdb@sourceware.org > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-25 20:08 ` Eli Zaretskii @ 2005-11-26 7:28 ` Christopher Faylor 2005-11-26 15:18 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-26 7:28 UTC (permalink / raw) To: gdb, Eli Zaretskii On Fri, Nov 25, 2005 at 09:53:17PM +0200, Eli Zaretskii wrote: >>Date: Fri, 25 Nov 2005 10:57:43 -0500 >>From: Daniel Jacobowitz >> >>>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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-26 7:28 ` Christopher Faylor @ 2005-11-26 15:18 ` Eli Zaretskii 2005-11-26 16:38 ` Daniel Jacobowitz 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-26 15:18 UTC (permalink / raw) To: gdb > Date: Fri, 25 Nov 2005 19:03:05 -0500 > From: Christopher Faylor <me@cgf.cx> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-26 15:18 ` Eli Zaretskii @ 2005-11-26 16:38 ` Daniel Jacobowitz 0 siblings, 0 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-26 16:38 UTC (permalink / raw) To: gdb On Sat, Nov 26, 2005 at 11:38:49AM +0200, Eli Zaretskii wrote: > > Date: Fri, 25 Nov 2005 19:03:05 -0500 > > From: Christopher Faylor <me@cgf.cx> > > > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 19:56 ` Eli Zaretskii 2005-11-23 20:13 ` Joel Brobecker @ 2005-11-23 20:41 ` Christopher Faylor 2005-11-24 4:56 ` Eli Zaretskii 2005-11-24 2:05 ` David Carlton 2 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-23 20:41 UTC (permalink / raw) To: gdb On Wed, Nov 23, 2005 at 09:34:11PM +0200, Eli Zaretskii wrote: >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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 20:41 ` Christopher Faylor @ 2005-11-24 4:56 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-24 4:56 UTC (permalink / raw) To: gdb > Date: Wed, 23 Nov 2005 15:13:37 -0500 > From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-23 19:56 ` Eli Zaretskii 2005-11-23 20:13 ` Joel Brobecker 2005-11-23 20:41 ` Christopher Faylor @ 2005-11-24 2:05 ` David Carlton 2005-11-24 6:17 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: David Carlton @ 2005-11-24 2:05 UTC (permalink / raw) To: gdb; +Cc: David Carlton On Wed, 23 Nov 2005 21:34:11 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: David Carlton <david.carlton@sun.com> >> Date: Tue, 22 Nov 2005 16:50:41 -0800 >>> How can I shape the documentation according to my ideas if I don't >>> have the final say? >> By acting exactly the way you do now. Anybody paying attention to >> GDB development knows that you're a very fast and responsive >> reviewer > But you see, this ``fast response'' argument works both ways: if I'm > a fast reviewer, why should it matter that only I can approve > documentation changes--a few hours of delay cannot possibly hurt > anyone or anything. Let me table that for a sec. > AFAIK and IIRC, Daniel suggested the change we are discussing > precisely _because_ of too slow response time of some responsible > maintainers, which was hurting development pace and driving away > contributors and potential maintainers. > So let's take my fast response time out of the equation. Let's > imagine that it takes me two or three weeks to review a patch. Or > let's imagine that I'm ill, or traveling, or otherwise incommunicado > from time to time. What would be your answer to my question then? My answer is that you would be much less effective in shaping the documentation in those circumstances. If I were submitting a patch including documentation, if there was agreement that the non-documentation parts of the patch were fine, if the documentation part seemed non-controversial to me, if you didn't respond fairly quickly to the doc patch, and if I had the authority to commit it all, I would do so. Your fast response time is a key factor (though not the only one) in why I suspect you would still be the major shaper of documentation in the new system. (A tangential comment: I think one of the most important lessons from the agile development community is the vast benefits of fast feedback.) ... > In other words (and sorry for over-simplification), you ask me to > assume that everybody else is nice and reasonable, and that, more > often than not, I will succeed in talking them into accepting my > opinions. I think you will on the matter of documentation, yes. I'm not so sure about djgpp - there, I suspect people will still listen to you, but there's probably more scope for reasonable people to disagree. (And, for that matter, for people to act unreasonable.) > Unfortunately, my experience is that this doesn't exactly > work that way. In fact, we invented the maintenance rules and we > are now rethinking them _precisely_ because the assumption that > everyone is always nice and reasonable doesn't seem to work too > well. ... > I can show examples of arguments, even disputes, with other > maintainers over issues where belief and personal attitudes > prevailed over objective reasoning, and we ended up in disagreement. > In those cases, where I had powers to veto a change, I could have > things my way, but where I didn't, things got done against my > opinions. Right. And I suspect the proposal's conflict resolution mechanisms are as good as they could be. I don't have any great suggestions for improving them, unfortunately. To get back to your question that I tabled above: + if I'm a fast reviewer, why should it matter that only I can approve + documentation changes--a few hours of delay cannot possibly hurt + anyone or anything. My first answer is "you could be wrong about whether a patch is a good one or not". Personally, I would (strongly) prefer not to adopt a conflict resolution mechanism where we designate certain people as always winning arguments about specific areas of GDB. My second answer is "you and documentation are both unique". If we were to adopt the new proposal with a modification that "Eli Zaretskii is the only person allowed to approve doc patches", I'm pretty sure that would be just fine, maybe even better than the proposal without that modification. But you respond faster than any other maintainer, and (I'm pretty sure) we're much less likely to get into substantive disagreement over doc changes than changes to other areas of the code. So I'm pretty leery about generalizing from that example. (Which is, admittedly, unfair of me, given that I started this subthread exactly by asking you to talk more about that example!) > So these things can and did happen, and I don't think it's fair to > ask someone to take responsibility for some part of GDB and at the > same time to tell them they should expect to fight with others who > have write access and who just happen to respond faster to RFAs. I have two different responses to this. 1) We could go along with that, and not ask anybody to take responsibility: we could have a notion of authorized committer without any notion of responsible committer. That wouldn't bother me at all; the proposal seems slightly too complex for me as-is, so I wouldn't mind simplifying it in that way. 2) It's not obvious to me that asking people to be responsible is unfair. And, as long as people have the right to say "no, I don't want to be responsible" and remain authorized to commit patches, it's also not obvious to me that it's urgent for us to figure out whether or not it's fair. Why not leave it up to people to decide if they want to take responsibility without being given any additional authority in return? David Carlton david.carlton@sun.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-24 2:05 ` David Carlton @ 2005-11-24 6:17 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-24 6:17 UTC (permalink / raw) To: David Carlton; +Cc: gdb > Cc: David Carlton <David.Carlton@sun.com> > From: David Carlton <david.carlton@sun.com> > Date: Wed, 23 Nov 2005 12:40:59 -0800 > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:44 ` Ian Lance Taylor 2005-11-18 18:51 ` Daniel Jacobowitz @ 2005-11-18 21:09 ` Eli Zaretskii 2005-11-18 21:32 ` Daniel Jacobowitz 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 21:09 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gdb > Cc: gdb@sourceware.org > From: Ian Lance Taylor <ian@airs.com> > 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 21:09 ` Eli Zaretskii @ 2005-11-18 21:32 ` Daniel Jacobowitz 0 siblings, 0 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 21:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ian Lance Taylor, gdb On Fri, Nov 18, 2005 at 11:09:44PM +0200, Eli Zaretskii wrote: > > 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". > > 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 21:10 ` Jim Blandy 2005-11-18 3:07 ` Daniel Jacobowitz @ 2005-11-18 12:14 ` Eli Zaretskii 1 sibling, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 12:14 UTC (permalink / raw) To: Jim Blandy; +Cc: gdb, cagney, jtc, fnf, Peter.Schauer, ezannoni > Date: Thu, 17 Nov 2005 13:10:21 -0800 > From: Jim Blandy <jimb@red-bean.com> > Cc: gdb@sourceware.org, Andrew Cagney <cagney@gnu.org>, > "J.T. Conklin" <jtc@acorntoolworks.com>, > Fred Fish <fnf@ninemoons.com>, > Peter Schauer <Peter.Schauer@regent.e-technik.tu-muenchen.de>, > Elena Zannoni <ezannoni@redhat.com> > > > 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. > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 4:48 Maintainer policy for GDB Daniel Jacobowitz [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> 2005-11-17 20:14 ` Eli Zaretskii @ 2005-11-17 23:10 ` Joel Brobecker 2005-11-18 12:42 ` Eli Zaretskii 2005-11-17 23:52 ` Mark Kettenis 2005-11-18 21:51 ` David Carlton 4 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-17 23:10 UTC (permalink / raw) To: gdb, Jim Blandy, Kevin Buettner, Andrew Cagney, J.T. Conklin, Fred Fish, Mark Kettenis, Peter Schauer, Stan Shebs, Michael Snyder, Eli Zaretskii, Elena Zannoni I'll try to put all the comments I have after having read the various messages that were posted. Overall, I like the proposal. > Patch Champions > > These volunteers track all patches submitted to the gdb-patches list. They > endeavor to prevent any posted patch from being overlooked; work with > contributors to meet GDB's coding style and general requirements, along with > FSF copyright assignments; remind (ping) responsible maintainers to review > patches; and ensure that contributors are given credit. I really like this idea. I can help out if nobody else volunteers. > Some maintainers are listed as responsible for patch review in particular > areas. If a maintainer is not currently able or willing to review patches, > please contact the global maintainers or the steering committee, who will > resolve the situation and find a replacement or assistant if necessary. I'm a bit unclear as who it is who should contact the GM or the SC. Is it the patch champion, or the submitter, or both? I'm more inclined to say "contact the GMs" first, and they will contact the SC if appropriate. Like some of us said previously, I'd like to keep the requests to the SC only for occasions where only the SC can solve the situation. If things can be sorted out by the GMs, let's do it that way, as they have a better knowledge of the GDB community. > Separating responsibility for patch review from authority for patch review > is a new concept for GDB; I believe the suggestion was Ian's. The more time > I've spent working on this proposal the more I've come to like it. I > envision the areas of responsibility as broad, but the areas of authority as > possibly more specialized. This is a winning concept, in my opinion. I agree with Eli that this concept needs to be made a little bit clearer, perhaps by adding a little paragraph, something resembling the above, as an introduction to the rest of the text. When I read the text, I was clear on what each category of developers had to do, as well as could do. Reading that same text after having a clear idea of this concept makes it have more sense. > I have always been in favor of the concept that global maintainers > should be able to approve patches anywhere, without having to wait for > area maintainers. If we don't trust each other enough for that, then > we need to work on the trust and/or the list of maintainers. Strongly agreed. About the voting system: I would also prefer to avoid this. The history of the GDB maintenance community since I joined shows that we're able to work together without unsolvable disagreements. In case a disagreement happens and cannot be resolved, which should be very seldom, the persons involved should present our arguments to the SC, and the SC makes a decision. They can vote if they want :-) (I heard they have a voting system in place). Eli said: > By contrast, you suggest to begin with unconditional trust. We > already tried that in the past, and we saw what happened. Why try > that again? why assume that what happened once, cannot happen again? I agree with Eli that an abusive developer/maintainer may happen again in the future. But I disagree that we should enforce stricter rules to prevent this from happening. This would be a waste of everybody's time for a situation which can only potentially happen very seldomly. How many developers have been bulies in GDB in the past 5 years? Let's not penalize the "nice guys", the majority of you, and deal with the few "bad guys" when the situation demands it. I'll take the example of something that I believe happened roughly a year ago with GCC. People complained about abusive commits from one of the global maintainers. I don't know the exact story, not following closely the GCC mailing lists, but I think the SC threatened to remove that person from the list of blanket maintainers, and perhaps even enacted on this decision. In any case, last I heard, he's playing much nicer now. (I know this guy personally, so I'm not criticizing him, just using his story as an example). So let's say we end up having somebody who is abusive and doesn't change his behavior after discussing the problem. Then let's collect the evidences of his behavior, and present them to the SC, who can then decide to revoke or not the priviledges that he's abusing from. > (Why CC everyone, if we all read the list?) I like this practice, because emails with my name in the recipients have a little flag, so I pay more attention to them (and look at them first). This is an easy way to make sure that the message gets some people's attention. -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 23:10 ` Joel Brobecker @ 2005-11-18 12:42 ` Eli Zaretskii 2005-11-18 15:05 ` Daniel Jacobowitz ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 12:42 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb, cagney, jtc, fnf, Peter.Schauer, ezannoni > Date: Thu, 17 Nov 2005 15:10:20 -0800 > From: Joel Brobecker <brobecker@adacore.com> > > 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. > > (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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 12:42 ` Eli Zaretskii @ 2005-11-18 15:05 ` Daniel Jacobowitz 2005-11-18 18:11 ` Eli Zaretskii 2005-11-18 17:53 ` Paul Gilliam 2005-11-18 19:50 ` Joel Brobecker 2 siblings, 1 reply; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-18 15:05 UTC (permalink / raw) To: gdb; +Cc: Joel Brobecker, cagney, jtc, fnf, Peter.Schauer, ezannoni On Fri, Nov 18, 2005 at 02:39:33PM +0200, Eli Zaretskii wrote: > Since Daniel sets up his mailer to prevent replies getting to him by > direct email, Huh? > 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.) -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 15:05 ` Daniel Jacobowitz @ 2005-11-18 18:11 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 18:11 UTC (permalink / raw) To: gdb, Joel Brobecker, cagney, jtc, fnf, Peter.Schauer, ezannoni; +Cc: gdb > Date: Fri, 18 Nov 2005 10:05:37 -0500 > From: Daniel Jacobowitz <drow@false.org> > Cc: Joel Brobecker <brobecker@adacore.com>, cagney@gnu.org, > jtc@acorntoolworks.com, fnf@ninemoons.com, > Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com > > On Fri, Nov 18, 2005 at 02:39:33PM +0200, Eli Zaretskii wrote: > > 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? > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 12:42 ` Eli Zaretskii 2005-11-18 15:05 ` Daniel Jacobowitz @ 2005-11-18 17:53 ` Paul Gilliam 2005-11-18 18:36 ` Eli Zaretskii 2005-11-18 19:50 ` Joel Brobecker 2 siblings, 1 reply; 101+ messages in thread From: Paul Gilliam @ 2005-11-18 17:53 UTC (permalink / raw) To: gdb, Eli Zaretskii Cc: Joel Brobecker, cagney, jtc, fnf, Peter.Schauer, ezannoni On Friday 18 November 2005 04:39, Eli Zaretskii wrote: > > Date: Thu, 17 Nov 2005 15:10:20 -0800 > > From: Joel Brobecker <brobecker@adacore.com> > > > > 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? > > > 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? > 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? > 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? > 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. > > > > (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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 17:53 ` Paul Gilliam @ 2005-11-18 18:36 ` Eli Zaretskii 2005-11-18 19:25 ` Joel Brobecker ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 18:36 UTC (permalink / raw) To: pgilliam; +Cc: gdb, brobecker, cagney, jtc, fnf, Peter.Schauer, ezannoni > From: Paul Gilliam <pgilliam@us.ibm.com> > Date: Fri, 18 Nov 2005 09:56:14 -0800 > Cc: Joel Brobecker <brobecker@adacore.com>, cagney@gnu.org, > jtc@acorntoolworks.com, fnf@ninemoons.com, > Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com > > On Friday 18 November 2005 04:39, Eli Zaretskii wrote: > > > Date: Thu, 17 Nov 2005 15:10:20 -0800 > > > From: Joel Brobecker <brobecker@adacore.com> > > > > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:36 ` Eli Zaretskii @ 2005-11-18 19:25 ` Joel Brobecker 2005-11-18 21:02 ` Paul Gilliam 2005-11-19 2:44 ` Christopher Faylor 2 siblings, 0 replies; 101+ messages in thread From: Joel Brobecker @ 2005-11-18 19:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: pgilliam, gdb, cagney, jtc, fnf, Peter.Schauer, ezannoni > 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 -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:36 ` Eli Zaretskii 2005-11-18 19:25 ` Joel Brobecker @ 2005-11-18 21:02 ` Paul Gilliam 2005-11-19 2:44 ` Christopher Faylor 2 siblings, 0 replies; 101+ messages in thread From: Paul Gilliam @ 2005-11-18 21:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, brobecker, cagney, jtc, fnf, Peter.Schauer, ezannoni On Friday 18 November 2005 10:31, Eli Zaretskii wrote: > > From: Paul Gilliam <pgilliam@us.ibm.com> > > Date: Fri, 18 Nov 2005 09:56:14 -0800 > > Cc: Joel Brobecker <brobecker@adacore.com>, cagney@gnu.org, > > jtc@acorntoolworks.com, fnf@ninemoons.com, > > Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com > > > > On Friday 18 November 2005 04:39, Eli Zaretskii wrote: > > > > Date: Thu, 17 Nov 2005 15:10:20 -0800 > > > > From: Joel Brobecker <brobecker@adacore.com> > > > > > > > > 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. > 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. > > > 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. > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 18:36 ` Eli Zaretskii 2005-11-18 19:25 ` Joel Brobecker 2005-11-18 21:02 ` Paul Gilliam @ 2005-11-19 2:44 ` Christopher Faylor 2005-11-19 10:56 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-19 2:44 UTC (permalink / raw) To: gdb On Fri, Nov 18, 2005 at 08:31:34PM +0200, Eli Zaretskii wrote: >> 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 2:44 ` Christopher Faylor @ 2005-11-19 10:56 ` Eli Zaretskii 2005-11-19 17:05 ` Christopher Faylor 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 10:56 UTC (permalink / raw) To: gdb > Date: Fri, 18 Nov 2005 21:44:55 -0500 > From: Christopher Faylor <me@cgf.cx> > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 10:56 ` Eli Zaretskii @ 2005-11-19 17:05 ` Christopher Faylor 2005-11-19 19:39 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-19 17:05 UTC (permalink / raw) To: gdb On Sat, Nov 19, 2005 at 12:56:49PM +0200, Eli Zaretskii wrote: >> 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 17:05 ` Christopher Faylor @ 2005-11-19 19:39 ` Eli Zaretskii 2005-11-19 22:21 ` Christopher Faylor 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 19:39 UTC (permalink / raw) To: gdb > Date: Sat, 19 Nov 2005 12:04:58 -0500 > From: Christopher Faylor <me@cgf.cx> > > On Sat, Nov 19, 2005 at 12:56:49PM +0200, Eli Zaretskii wrote: > >> 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? ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 19:39 ` Eli Zaretskii @ 2005-11-19 22:21 ` Christopher Faylor 2005-11-19 22:23 ` Christopher Faylor 2005-11-19 22:55 ` Eli Zaretskii 0 siblings, 2 replies; 101+ messages in thread From: Christopher Faylor @ 2005-11-19 22:21 UTC (permalink / raw) To: gdb On Sat, Nov 19, 2005 at 09:39:33PM +0200, Eli Zaretskii wrote: >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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 22:21 ` Christopher Faylor @ 2005-11-19 22:23 ` Christopher Faylor 2005-11-19 22:25 ` Christopher Faylor 2005-11-19 22:55 ` Eli Zaretskii 1 sibling, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-19 22:23 UTC (permalink / raw) To: gdb On Sat, Nov 19, 2005 at 05:21:30PM -0500, Christopher Faylor wrote: >On Sat, Nov 19, 2005 at 09:39:33PM +0200, Eli Zaretskii wrote: >>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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 22:23 ` Christopher Faylor @ 2005-11-19 22:25 ` Christopher Faylor 2005-11-19 22:54 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-19 22:25 UTC (permalink / raw) To: gdb On Sat, Nov 19, 2005 at 05:23:09PM -0500, Christopher Faylor wrote: >On Sat, Nov 19, 2005 at 05:21:30PM -0500, Christopher Faylor wrote: >>On Sat, Nov 19, 2005 at 09:39:33PM +0200, Eli Zaretskii wrote: >>>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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 22:25 ` Christopher Faylor @ 2005-11-19 22:54 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 22:54 UTC (permalink / raw) To: gdb > Date: Sat, 19 Nov 2005 17:25:05 -0500 > From: Christopher Faylor <me@cgf.cx> > > >>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! ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 22:21 ` Christopher Faylor 2005-11-19 22:23 ` Christopher Faylor @ 2005-11-19 22:55 ` Eli Zaretskii 2005-11-20 5:28 ` Joel Brobecker 1 sibling, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-19 22:55 UTC (permalink / raw) To: gdb > Date: Sat, 19 Nov 2005 17:21:30 -0500 > From: Christopher Faylor <me@cgf.cx> > > 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 ;-) ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-19 22:55 ` Eli Zaretskii @ 2005-11-20 5:28 ` Joel Brobecker 2005-11-20 19:22 ` Eli Zaretskii 0 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-20 5:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > 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! -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-20 5:28 ` Joel Brobecker @ 2005-11-20 19:22 ` Eli Zaretskii 2005-11-20 21:55 ` Christopher Faylor 0 siblings, 1 reply; 101+ messages in thread From: Eli Zaretskii @ 2005-11-20 19:22 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb > Date: Sat, 19 Nov 2005 21:28:06 -0800 > From: Joel Brobecker <brobecker@adacore.com> > Cc: gdb@sourceware.org > > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-20 19:22 ` Eli Zaretskii @ 2005-11-20 21:55 ` Christopher Faylor 2005-11-20 22:01 ` Daniel Jacobowitz 0 siblings, 1 reply; 101+ messages in thread From: Christopher Faylor @ 2005-11-20 21:55 UTC (permalink / raw) To: gdb On Sun, Nov 20, 2005 at 09:22:33PM +0200, Eli Zaretskii wrote: >>Date: Sat, 19 Nov 2005 21:28:06 -0800 >>From: Joel Brobecker >> >>> 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-20 21:55 ` Christopher Faylor @ 2005-11-20 22:01 ` Daniel Jacobowitz 0 siblings, 0 replies; 101+ messages in thread From: Daniel Jacobowitz @ 2005-11-20 22:01 UTC (permalink / raw) To: gdb On Sun, Nov 20, 2005 at 04:55:48PM -0500, Christopher Faylor wrote: > On Sun, Nov 20, 2005 at 09:22:33PM +0200, Eli Zaretskii wrote: > >>Date: Sat, 19 Nov 2005 21:28:06 -0800 > >>From: Joel Brobecker > >> > >>> 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. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 12:42 ` Eli Zaretskii 2005-11-18 15:05 ` Daniel Jacobowitz 2005-11-18 17:53 ` Paul Gilliam @ 2005-11-18 19:50 ` Joel Brobecker 2005-11-18 21:41 ` Eli Zaretskii 2 siblings, 1 reply; 101+ messages in thread From: Joel Brobecker @ 2005-11-18 19:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb, cagney, jtc, fnf, Peter.Schauer, ezannoni 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). -- Joel ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-18 19:50 ` Joel Brobecker @ 2005-11-18 21:41 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-18 21:41 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb, cagney, jtc, fnf, Peter.Schauer, ezannoni > Date: Fri, 18 Nov 2005 11:50:40 -0800 > From: Joel Brobecker <brobecker@adacore.com> > Cc: gdb@sourceware.org, cagney@gnu.org, jtc@acorntoolworks.com, fnf@ninemoons.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, ezannoni@redhat.com > > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 4:48 Maintainer policy for GDB Daniel Jacobowitz ` (2 preceding siblings ...) 2005-11-17 23:10 ` Joel Brobecker @ 2005-11-17 23:52 ` Mark Kettenis 2005-11-18 21:51 ` David Carlton 4 siblings, 0 replies; 101+ messages in thread From: Mark Kettenis @ 2005-11-17 23:52 UTC (permalink / raw) To: drow Cc: gdb, jimb, kevinb, cagney, jtc, fnf, Peter.Schauer, shebs, msnyder, eliz, ezannoni > Date: Wed, 16 Nov 2005 23:48:01 -0500 > From: Daniel Jacobowitz <drow@false.org> > > So, first some proposed text, and then some additional rationale. Please, > let the list know your opinions. Here we go: > 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-17 4:48 Maintainer policy for GDB Daniel Jacobowitz ` (3 preceding siblings ...) 2005-11-17 23:52 ` Mark Kettenis @ 2005-11-18 21:51 ` David Carlton 4 siblings, 0 replies; 101+ messages in thread From: David Carlton @ 2005-11-18 21:51 UTC (permalink / raw) To: gdb On Wed, 16 Nov 2005 23:48:01 -0500, Daniel Jacobowitz <drow@false.org> said: > 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 david.carlton@sun.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB @ 2005-11-27 4:50 Michael Snyder 2005-11-27 4:59 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Michael Snyder @ 2005-11-27 4:50 UTC (permalink / raw) To: gdb 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-27 4:50 Michael Snyder @ 2005-11-27 4:59 ` Eli Zaretskii 2005-11-27 5:00 ` Ian Lance Taylor 2005-11-27 19:18 ` Christopher Faylor 2 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-27 4:59 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb > Date: Sat, 26 Nov 2005 20:30:11 -0800 > From: Michael Snyder <msnyder@redhat.com> > > 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. In your scenario: > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-27 4:50 Michael Snyder 2005-11-27 4:59 ` Eli Zaretskii @ 2005-11-27 5:00 ` Ian Lance Taylor 2005-11-27 19:22 ` Eli Zaretskii 2005-11-27 19:18 ` Christopher Faylor 2 siblings, 1 reply; 101+ messages in thread From: Ian Lance Taylor @ 2005-11-27 5:00 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb Michael Snyder <msnyder@redhat.com> writes: > 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-27 5:00 ` Ian Lance Taylor @ 2005-11-27 19:22 ` Eli Zaretskii 0 siblings, 0 replies; 101+ messages in thread From: Eli Zaretskii @ 2005-11-27 19:22 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: msnyder, gdb > Cc: gdb@sources.redhat.com > From: Ian Lance Taylor <ian@airs.com> > 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. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Maintainer policy for GDB 2005-11-27 4:50 Michael Snyder 2005-11-27 4:59 ` Eli Zaretskii 2005-11-27 5:00 ` Ian Lance Taylor @ 2005-11-27 19:18 ` Christopher Faylor 2 siblings, 0 replies; 101+ messages in thread From: Christopher Faylor @ 2005-11-27 19:18 UTC (permalink / raw) To: gdb, Michael Snyder On Sat, Nov 26, 2005 at 08:30:11PM -0800, Michael Snyder wrote: >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." 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 ^ permalink raw reply [flat|nested] 101+ messages in thread
end of thread, other threads:[~2005-11-27 19:22 UTC | newest] Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-11-17 4:48 Maintainer policy for GDB Daniel Jacobowitz [not found] ` <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> 2005-11-17 6:44 ` Fwd: " Jim Blandy 2005-11-17 14:04 ` Daniel Jacobowitz 2005-11-17 17:07 ` Jim Blandy 2005-11-17 20:38 ` Jim Blandy 2005-11-17 20:15 ` Eli Zaretskii 2005-11-17 20:16 ` Eli Zaretskii 2005-11-17 20:14 ` Eli Zaretskii 2005-11-17 21:10 ` Jim Blandy 2005-11-18 3:07 ` Daniel Jacobowitz 2005-11-18 3:26 ` Joel Brobecker 2005-11-18 3:30 ` Daniel Jacobowitz 2005-11-18 3:33 ` Joel Brobecker 2005-11-18 3:46 ` Wu Zhou 2005-11-18 11:09 ` Andrew STUBBS 2005-11-18 11:46 ` Eli Zaretskii 2005-11-18 11:59 ` Andrew STUBBS 2005-11-18 13:15 ` Eli Zaretskii 2005-11-18 15:26 ` Daniel Jacobowitz 2005-11-18 18:24 ` Eli Zaretskii 2005-11-18 18:44 ` Ian Lance Taylor 2005-11-18 18:51 ` Daniel Jacobowitz 2005-11-18 21:40 ` Eli Zaretskii 2005-11-18 21:46 ` Daniel Jacobowitz 2005-11-18 22:33 ` Eli Zaretskii 2005-11-18 22:41 ` Daniel Jacobowitz 2005-11-19 9:34 ` Eli Zaretskii 2005-11-18 21:51 ` Jim Blandy 2005-11-18 22:29 ` Eli Zaretskii 2005-11-19 0:34 ` Jim Blandy 2005-11-19 10:54 ` Eli Zaretskii 2005-11-21 7:52 ` Jim Blandy 2005-11-21 22:35 ` Eli Zaretskii 2005-11-18 22:46 ` David Carlton 2005-11-19 10:38 ` Eli Zaretskii 2005-11-23 1:28 ` David Carlton 2005-11-23 19:56 ` Eli Zaretskii 2005-11-23 20:13 ` Joel Brobecker 2005-11-24 4:51 ` Eli Zaretskii 2005-11-24 20:36 ` Joel Brobecker 2005-11-24 20:47 ` Eli Zaretskii 2005-11-24 21:20 ` Joel Brobecker 2005-11-25 3:07 ` Daniel Jacobowitz 2005-11-25 8:36 ` Christopher Faylor 2005-11-25 8:37 ` Eli Zaretskii 2005-11-25 17:07 ` Daniel Jacobowitz 2005-11-25 19:53 ` Joel Brobecker 2005-11-25 20:43 ` Eli Zaretskii 2005-11-25 20:10 ` Eli Zaretskii 2005-11-25 21:03 ` Daniel Jacobowitz 2005-11-25 21:38 ` Eli Zaretskii 2005-11-25 23:04 ` Daniel Jacobowitz 2005-11-25 23:42 ` Mark Kettenis 2005-11-26 0:03 ` Daniel Jacobowitz 2005-11-26 9:38 ` Eli Zaretskii 2005-11-26 9:31 ` Eli Zaretskii 2005-11-27 15:07 ` Daniel Jacobowitz 2005-11-28 8:51 ` Eli Zaretskii 2005-11-25 9:23 ` Eli Zaretskii 2005-11-25 16:04 ` Daniel Jacobowitz 2005-11-25 20:08 ` Eli Zaretskii 2005-11-26 7:28 ` Christopher Faylor 2005-11-26 15:18 ` Eli Zaretskii 2005-11-26 16:38 ` Daniel Jacobowitz 2005-11-23 20:41 ` Christopher Faylor 2005-11-24 4:56 ` Eli Zaretskii 2005-11-24 2:05 ` David Carlton 2005-11-24 6:17 ` Eli Zaretskii 2005-11-18 21:09 ` Eli Zaretskii 2005-11-18 21:32 ` Daniel Jacobowitz 2005-11-18 12:14 ` Eli Zaretskii 2005-11-17 23:10 ` Joel Brobecker 2005-11-18 12:42 ` Eli Zaretskii 2005-11-18 15:05 ` Daniel Jacobowitz 2005-11-18 18:11 ` Eli Zaretskii 2005-11-18 17:53 ` Paul Gilliam 2005-11-18 18:36 ` Eli Zaretskii 2005-11-18 19:25 ` Joel Brobecker 2005-11-18 21:02 ` Paul Gilliam 2005-11-19 2:44 ` Christopher Faylor 2005-11-19 10:56 ` Eli Zaretskii 2005-11-19 17:05 ` Christopher Faylor 2005-11-19 19:39 ` Eli Zaretskii 2005-11-19 22:21 ` Christopher Faylor 2005-11-19 22:23 ` Christopher Faylor 2005-11-19 22:25 ` Christopher Faylor 2005-11-19 22:54 ` Eli Zaretskii 2005-11-19 22:55 ` Eli Zaretskii 2005-11-20 5:28 ` Joel Brobecker 2005-11-20 19:22 ` Eli Zaretskii 2005-11-20 21:55 ` Christopher Faylor 2005-11-20 22:01 ` Daniel Jacobowitz 2005-11-18 19:50 ` Joel Brobecker 2005-11-18 21:41 ` Eli Zaretskii 2005-11-17 23:52 ` Mark Kettenis 2005-11-18 21:51 ` David Carlton 2005-11-27 4:50 Michael Snyder 2005-11-27 4:59 ` Eli Zaretskii 2005-11-27 5:00 ` Ian Lance Taylor 2005-11-27 19:22 ` Eli Zaretskii 2005-11-27 19:18 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).