From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Maintainership Date: Sun, 12 Jan 2014 10:37:10 +0100 Organization: Organization?!? Message-ID: <87d2jxee2h.fsf@fencepost.gnu.org> References: <20140112040940.GC32704@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389519464 13739 80.91.229.3 (12 Jan 2014 09:37:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jan 2014 09:37:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 12 10:37:47 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W2HUI-00081l-Lv for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 10:37:46 +0100 Original-Received: from localhost ([::1]:36992 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2HUE-0004DY-4O for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 04:37:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2HU5-0004D4-JR for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:37:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2HU0-0005Rw-54 for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:37:33 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:34125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2HTz-0005Rs-Uo for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:37:28 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W2HTx-0007kv-Tw for emacs-devel@gnu.org; Sun, 12 Jan 2014 10:37:25 +0100 Original-Received: from x2f3b2f2.dyn.telefonica.de ([2.243.178.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jan 2014 10:37:25 +0100 Original-Received: from dak by x2f3b2f2.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Jan 2014 10:37:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f3b2f2.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:NhcSGfjV1uvIFsYumldEwcqHoz8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168162 Archived-At: "Eric S. Raymond" writes: > Stefan Monnier : >> It's nice to be a dictator, but it takes too much time, so in order to >> try and reduce this load, I'd like to dilute my dictatorship a bit. >> >> To a large extent, this has already been the case, but I think it's >> worth stating it more formally: if Glenn, Eli, Richard, Yidong, Handa, or >> Jan agrees with a change, then you don't need my agreement. >> IOW you only need my opinion if none of them has an opinion or if >> there's a disagreement. > > OK. The following question is *not* an attempt to be contentious; I'm > trying to figure out how this is supposed to work, and help everyone > else figure out too. > > You have expressed "100% agreement" with a post objecting to me doing /etc > cleanup during feature freeze. > > On the other hand, Richard has approved the idea and actively > assisted. Where is the conflict? It's something that should be done but not committed now. > If I understand your intention correctly, that makes the completion of > the /etc cleanup changes an approved project. A project is one thing. Committing a change to the release candidate is another. Now I don't want to rain on Stefan's parade, but that difference is pretty much exactly why it makes sense that any particular release branch is best served by a _single_ responsible person making the calls. After the consolidation period is considered reasonably complete, the release branch is branched off and from that time on, _only_ the version dictator will cherry-pick changes into that branch until the actual release happens. The problem with multiple parallel quality managers which are possibly partly not fully dedicated to the release quality management means that the quality threshold of changes to go in is worse than even the individual minimum (since the feeling of shared responsibility lowers the diligence even more). > I can cheerfully live with either theory - I've certainly got enough > on my task list to occupy me for a while. So I'm not pushing for > either outcome in particular, I just want to know how the decision > procedure works. With my usual pessimism, my guess would be "not". -- David Kastrup