From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22578 invoked by alias); 20 Feb 2003 02:48:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22567 invoked from network); 20 Feb 2003 02:48:37 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 20 Feb 2003 02:48:37 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D92CE2ED1; Wed, 19 Feb 2003 21:53:21 -0500 (EST) Message-ID: <3E544321.8010803@redhat.com> Date: Thu, 20 Feb 2003 02:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00393.txt.bz2 > I agree with what Daniel has said here. I'm concerned that some > people have misunderstood his points, so I'll put it differently. > > I think GDB could get better use of the contributors it has now by > adjusting the rules for patch approval. > > - Slow patch review is a real problem on GDB --- even acknowledging > the legitimate reasons for some delays that Elena has mentioned. I found myself babysitting a short list of largely dormant maintainers using regular pings. That was grosely inefficient. I've now given that one up and have moved on to filing unreviewed patches in the bug database - worse for the contributor waiting on a dormant maintainer but better for me and the other active maintainers. It has been in place for ~a month and, in my opinion, has definitly improved things. There is a one-stop-shop where active [global] maintainers can either find a backlog of patches or areas that need work. I just wish that the tool being used was less primative :-( > - It's true that "... some maintainers should try to review patches in > their areas of responsibility more often", but merely saying so > doesn't have any effect. Folks have been saying that ever since > Cygnus loosened its grip on GDB and the process opened to the > public. That statement seems to express a hope that the maintainers > will somehow "wake up" and everything will get better. It's been > years, now, and we need to stop waiting for this to happen. Let's > work with the people we've got, rather than hoping they'll transform > themselves somehow. And the vast majority of maintainers do a pretty good job. > - If we accept that the maintainers' behavior is stable, then the next > alternative is to adjust the organization that they operate under. > Is there some way to re-organize the people we have, accepting their > job committments and personal limitations (I have myself in mind > here as much as anyone else, so don't be affronted), so that things > progress better? Is the current organization optimal? Stable or reliable? Most maintainers are reliable, a small few, though, seem to keep falling asleep at the wheel. Having such people as developers isn't a problem. Having such people hold key responsabilities (such as being in the loop to review patches) is. Andrew