From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18229 invoked by alias); 19 Nov 2005 10:38:01 -0000 Received: (qmail 18218 invoked by uid 22791); 19 Nov 2005 10:37:58 -0000 Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 19 Nov 2005 10:37:58 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-251-47.inter.net.il [83.130.251.47]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id CZV20645 (AUTH halo1); Sat, 19 Nov 2005 12:37:49 +0200 (IST) Date: Sat, 19 Nov 2005 10:38:00 -0000 Message-Id: From: Eli Zaretskii To: David Carlton CC: gdb@sourceware.org In-reply-to: (message from David Carlton on Fri, 18 Nov 2005 14:46:45 -0800) Subject: Re: Maintainer policy for GDB Reply-to: Eli Zaretskii References: <20051117140353.GA11432@nevyn.them.org> <20051117044801.GA4705@nevyn.them.org> <8f2776cb0511162240q6f550008udda9803b5253fd88@mail.gmail.com> <20051118030711.GB31581@nevyn.them.org> <20051118152618.GB9100@nevyn.them.org> <20051118185135.GA13986@nevyn.them.org> 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/msg00422.txt.bz2 > From: David Carlton > Date: Fri, 18 Nov 2005 14:46:45 -0800 > > > In other words, if responsibility doesn't come with some unique > > authority, who will want such a responsibility? > > One possible way to treat this question is as an empirical one. To > that end, one could ask people currently listed in MAINTAINERS as > maintaining a given domain whether they would prefer to remain > responsible for maintaining, or merely authorized, and why. For > example, would you be interested in being responsible for djgpp and/or > documentation under the proposed new rules? If so, why? Thanks, that was a useful thought experiment. After thinking about this for a while, I concluded that my main reasons for being interested in becoming a responsible maintainer is that I'd like to influence the development and maintenance of those specific areas according to ideas I have. For example, I might wish to make sure the manual is well indexed: each important concept has a @cindex entry, each command has a @kindex entry, the index entries are well thought and easy to guess, and allow the reader to use the manual as a reference, etc. Now, under the suggested rules, somebody who is authorized to approve patches to the documentation could commit changes that don't fit my plan about indexing, without asking me, right? How can I shape the documentation according to my ideas if I don't have the final say? The only way would be to revert changes and/or redo them myself. Under the current scheme, I can refuse the approval unless and until the contributor reworks the changes according to my standards. With that authority gone, I'm left dead in the water; doing everything myself is not an option for me, given my chronic lack of free time, and starting a revert war or going to the SC over disputes about @cindex is either time-consuming or childishly silly or both.