From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15825 invoked by alias); 25 Nov 2005 23:04:20 -0000 Received: (qmail 15808 invoked by uid 22791); 25 Nov 2005 23:04:18 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Nov 2005 23:04:16 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jAPN3f1G025213; Sat, 26 Nov 2005 00:03:41 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jAPN3eSP012369; Sat, 26 Nov 2005 00:03:40 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jAPN3ewj023750; Sat, 26 Nov 2005 00:03:40 +0100 (CET) Date: Fri, 25 Nov 2005 23:42:00 -0000 Message-Id: <200511252303.jAPN3ewj023750@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sourceware.org In-reply-to: <20051125213849.GA8364@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 25 Nov 2005 16:38:49 -0500) Subject: Re: Maintainer policy for GDB References: <20051124171814.GI1635@adacore.com> <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> 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/msg00569.txt.bz2 > Date: Fri, 25 Nov 2005 16:38:49 -0500 > From: Daniel Jacobowitz > > On Fri, Nov 25, 2005 at 11:02:49PM +0200, Eli Zaretskii wrote: > > If that is so, we will watch most of the current maintainers being > > politely asked to step down. When the last of them goes, you can then > > have your suggested approval procedure, since most areas will be left > > without RMs ;-) > > Hmm. We can manage better than that. But, let's worry about the > details of that a little later in the process, please. > > We need a concrete value for N. Joel has suggested anything from a > week to ten days. I would prefer a week or less. Chris suggested a > month, you suggested three weeks in response. > > Can we all reach compromise on two weeks? 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. 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. Mark