From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5bVw-0002hR-8W for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 15:14:00 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitcoins.info designates 70.90.2.18 as permitted sender) client-ip=70.90.2.18; envelope-from=milly@bitcoins.info; helo=mail.help.org; Received: from mail.help.org ([70.90.2.18]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1Z5bVv-0002ai-Bd for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 15:14:00 +0000 Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Thu, 18 Jun 2015 11:13:51 -0400 Message-ID: <5582E025.7000704@bitcoins.info> Date: Thu, 18 Jun 2015 11:13:41 -0400 From: Milly Bitcoin User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bitcoin Dev References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> <20150618140544.GA7674@amethyst.visucore.com> <5582DB62.8000700@bitcoins.info> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Z5bVv-0002ai-Bd Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:14:00 -0000 >Impacts, yes, decider, no. Multiple ACKs are required from developers who will not act if the community will disagree with the change. >The users ultimately choose by deciding which software to download, and that dictates the range of choices available. That is what I mean by a cultish reply. Just saying the users ultimately decide is not an adequate explanation of the situation. You are talking hard fork if someone doesn't like it. If 10% of the users don't like there is nothing they can do unless they want to operate an altcoin. You are not going to resolve anything by repeating these types of replies that really have no applicability in the real world. The person who approves the pull request (no matter what the process is beforehand) is effectively the decider. Also, as pointed out, there is no real process in place. Making offhand statements that "multiple ACKs are required" without describing a real process just sends people down a rat hole like this block size debate. Providing these (non) answers instead of developing a real process is why there is so much contention now. Russ