From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13265 invoked by alias); 18 Nov 2005 15:26:21 -0000 Received: (qmail 13258 invoked by uid 22791); 18 Nov 2005 15:26:21 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Nov 2005 15:26:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ed882-0002WJ-Ns for gdb@sourceware.org; Fri, 18 Nov 2005 10:26:18 -0500 Date: Fri, 18 Nov 2005 15:26:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Maintainer policy for GDB Message-ID: <20051118152618.GB9100@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20051117044801.GA4705@nevyn.them.org> <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> <8f2776cb0511162244u5274377m70684a364a8a7edd@mail.gmail.com> <20051117140353.GA11432@nevyn.them.org> <20051117044801.GA4705@nevyn.them.org> <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> <20051118030711.GB31581@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00389.txt.bz2 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