From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29732 invoked by alias); 20 Feb 2003 20:11:05 -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 29604 invoked by uid 0); 20 Feb 2003 20:10:59 -0000 Resent-Message-ID: <20030220201059.29603.qmail@sources.redhat.com> Received: (qmail 32474 invoked from network); 20 Feb 2003 06:44:12 -0000 Received: from unknown (HELO mxout3.netvision.net.il) (194.90.9.24) by 172.16.49.205 with SMTP; 20 Feb 2003 06:44:12 -0000 Received: from is.elta.co.il ([207.232.27.5]) by mxout3.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with SMTP id <0HAL00AJHHCREI@mxout3.netvision.net.il> for gdb@sources.redhat.com; Thu, 20 Feb 2003 08:43:40 +0200 (IST) Received: from eltinlb1.elta.co.il (172.16.0.122) by ELTIGW1.elta.co.il; Thu, 20 Feb 2003 08:44:46 +0200 Received: from ELTIMAIL1.elta.co.il ([172.16.0.103]) by eltinlb1.elta.co.il with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Feb 2003 08:44:42 +0200 Date: Thu, 20 Feb 2003 20:11:00 -0000 From: Zaretskii Eli Subject: RE: [maint] The GDB maintenance process To: Jim Blandy , gdb@sources.redhat.com Message-Id: <4D19136444628A40840EFE8C5AE04147017A43@ELTIMAIL1.elta.co.il> MIME-Version: 1.0 X-Mimeole: Produced By Microsoft Exchange V6.0.6249.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Content-Class: urn:content-classes:message X-Privawall-Id: 0002556710ab X-Originalarrivaltime: 20 Feb 2003 06:44:42.0890 (UTC) FILETIME=[8C8DB6A0:01C2D8AB] Resent-From: root@sourceware.org Resent-Date: Thu, 20 Feb 2003 20:10:59 +0000 X-SW-Source: 2003-02/txt/msg00447.txt.bz2 This message was scanned for viruses and other malicious code by PrivaWall. This mail was sent from ELTA SYS LTD. > From: Jim Blandy [mailto:jimb@redhat.com] > Sent: Wednesday, February 19, 2003 4:18 AM > > - 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. GDB maintenance is not the only place that needs to deal with that problem. We don't have to reinvent the wheel, or feel that we face an insoluble problem, and neither do we need to make drastic changes in the current commit paradigms. More to the point, if we think that some maintainers don't respond fast enough, we could bring more maintainers on board. The primary candidates for becoming new maintainers are those people who push significant patches in the areas where the current maintainers are slow. In other words, let those who are unhappy with the current situation put their money where their mouth is and help with the burden. We could also ask a maintainer to step down if he/she cannot keep up with his/her duties in a timely manner, or we could grant the head maintainer (or a group of veteran maintainers) powers to declare that someone has effectively stepped down due to lack of responsiveness. These are all minor modifications to the existing model. If someone thinks that they will never be effective enough, let them explain why. I'm not against changing the model to something like commit-then-review, mind you. But please don't underestimate the implications of this on the social dynamics within our team: reverting changes, while technically easy, tends to leave bad after-taste and hurts relationships; the arguments about whether to revert a patch tend to be ugly. We should ask ourselves if we are willing to pay that price. This message is processed by the PrivaWall Email Security Server.