From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25668 invoked by alias); 25 Mar 2004 19:27:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25657 invoked from network); 25 Mar 2004 19:27:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 25 Mar 2004 19:27:57 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2PJRuWA020938 for ; Thu, 25 Mar 2004 14:27:56 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2PJRtM24481; Thu, 25 Mar 2004 14:27:55 -0500 Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i2PJRsC20925; Thu, 25 Mar 2004 11:27:54 -0800 Message-ID: <406332B9.7090903@redhat.com> Date: Thu, 25 Mar 2004 19:27:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030922 MIME-Version: 1.0 To: Ian Lance Taylor CC: Joel Brobecker , Robert Dewar , gdbheads@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [Gdbheads] A small patch case study, -file-list-exec-source-files References: <20040225040059.GB19094@white> <16456.65451.461753.66554@localhost.redhat.com> <20040306155700.GA9439@white> <20040311132508.GA2504@white> <20040323130900.GA17339@white> <40605C9F.2050700@gnat.com> <20040325043648.GA20454@white> <20040325055925.GS1104@gnat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: 0 X-SW-Source: 2004-03/txt/msg00629.txt.bz2 Ian Lance Taylor wrote: > Joel Brobecker writes: > > >>GDB is a volunteer work! > > > I want to note that this is only partially true. In fact there are a > number of people who are paid to work on gdb. It's not clear whether > anybody is paid specifically to maintain gdb. When I was at Cygnus I > was paid to maintain the GNU binutils, though that was certainly not > my only job. I don't know whether Red Hat has carried that sort of > thing forward. Well now... there's a fine point here. Red Hat, Monte Vista, Apple, HP, and other organizations may pay some people to work on GDB, but only in some limited sense do those organizations pay their employees to review other people's patches. And to whatever degree that is true (eg. my job description does include spending a certain part of my time working as an FSF maintainer), all it does is modify who's doing the volunteering: to some degree it's me, and to some degree it's Red Hat. It's still donated work, the FSF isn't paying for it, and I'm still 100 percent a volunteer. I wouldn't lose my job if I announced that I didn't want to serve as an FSF maintainer any more. All that would happen would be that the work load of the other maintainers would go up, since they would have to review all of my work. >>If you keep insisting that a maintainer have to review patches within a >>given timeframe and that they should step down if they can't, then I >>think we're going to lose a lot of maintainers. Will GDB really be >>better off? I think not. > > > I would say that the issue is how to best keep gdb moving forward. That is one valid way of looking at it, Ian, but it isn't the only way. All of us maintainers are people too, and it's perfectly legitimate for us to have our own agendas and our own interests in mind, in addition to those of gdb and the FSF. By becoming FSF volunteers, we did not become monks -- we did not give up the right to our own self-hood and our own egos. To make a team work, we have to get those egos to function smoothly together -- but that doesn't mean pretending that they don't exist, or making decisions on the basis that the only thing that matters is gdb. The people working on gdb matter too. > On the one hand, if we require prompt patch review, then gdb may lose > maintainers. On the other hand, if patches are not reviewed promptly, > then gdb may lost contributors. There is a balance between the two. > The goal is to keep the balance from tipping too far to one side or > the other. > > I don't know myself whether the balance is indeed tipped too far for > gdb. As I've said, I do think that maintainers should treat patch > review as their most important activity. > > >>I think you're looking at the wrong solution. The real solution, >>according to me, is not to push away good maintainers that have only so >>much time, but to help the group of maintainers to act as a team. >>When one maintainer is too busy, then the rest of the team should be >>allowed to step up and help the busy maintainer by reviewing patches >>and answering emails in his place. The real problem is that GDB >>currently has bottlenecks, and that's the issue that needs solving, >>one way or the other. > > > Yes, this sort of approach has been proposed by several different > people, including some gdb maintainers.