From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2228 invoked by alias); 25 Nov 2005 23:42:32 -0000 Received: (qmail 2216 invoked by uid 22791); 25 Nov 2005 23:42:31 -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.1) with ESMTP; Fri, 25 Nov 2005 23:42:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EfnD1-0002mC-Df; Fri, 25 Nov 2005 18:42:27 -0500 Date: Sat, 26 Nov 2005 00:03:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org Subject: Re: Maintainer policy for GDB Message-ID: <20051125234227.GA10612@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org References: <20051125030605.GA20073@nevyn.them.org> <20051125052810.GA23958@trixie.casa.cgf.cx> <20051125160454.GB29028@nevyn.them.org> <20051125204347.GA7107@nevyn.them.org> <20051125213849.GA8364@nevyn.them.org> <200511252303.jAPN3ewj023750@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511252303.jAPN3ewj023750@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00570.txt.bz2 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