From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5id5-0003ON-TX for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 22:49:51 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z5id4-0004mL-I0 for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 22:49:51 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id B4E5E4233A for ; Thu, 18 Jun 2015 22:49:44 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 7264D4248D Message-ID: <55834B07.9000806@riseup.net> Date: Thu, 18 Jun 2015 15:49:43 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <55828737.6000007@riseup.net> <20150618111407.GA6690@amethyst.visucore.com> <5582E3FE.7010206@bitcoins.info> <20150618154640.GA7840@amethyst.visucore.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.7 (-) 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5id4-0004mL-I0 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 22:49:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Regarding this proposal from Mike Hearn to remove consensus process from the BIP, which I think is unsound philosophy. I will address this briefly below. On 06/18/2015 09:05 AM, Mike Hearn wrote: > So then: make a proposal for a better process, post it to this > list. >=20 >=20 > Alright. Here is a first cut of my proposal. It can be inserted > into an amended BIP 1 after "What belongs in a successful BIP?". > Let me know what you think. >=20 >=20 >=20 > The following section applies to BIPs that affect the block chain=20 > consensus rules or the peer to peer protocol and thus require > changes to Bitcoin Core. >=20 > Once a draft BIP has been submitted to bitcoin-development for=20 > consideration, the Bitcoin Core maintainer will deliver a > preliminary yes/no verdict within three weeks. For many things, that will simply be too fast. It is better to allow the primary maintainer to collaborate with other people who normally work on the code and determine what the schedule will be based on life, volume of work, and so on. > This verdict may be informed by the debate that has taken part in > the previous three weeks. If more time is required, the maintainer > is required to request an extension from the BIP author, who may > then elect to force an immediate decision (risking a no), or > choosing to allow more time. Again, this three week thing doesn't work. But assume for a moment that there is a certain amount of time that is such and so and it is set by the maintainer. The notion that the maintainer would be "required" to request an extension from the BIP author is sheer lunacy. There is no need to codify the actions of the project maintainer such that he/she would be needing to be subject to the whims of whatever BIP author. In like manner, a BIP author should not have to be subject to forever delay of a BIP due to inaction of a maintainer, but should have an answer regarding whether it can be assigned a number, published as draft and so forth after a reasonable time. To me, a "reasonable time" is something that should be discussed amongst the maintainer, those who work regularly on code, and the BIP author. >=20 > The verdict will meet the following criteria: >=20 > * It will address the latest version of the BIP at the time the=20 > verdict is rendered. >=20 > * In case of a rejection, it will spell out and describe the > technical rationale for this decision. Opinions held by other > people are not considered technical rationales: if the maintainer > agrees with a technical point made during discussion, he must own > that opinion for himself. Therefore no BIP will be rejected on > grounds of controversy, disagreement, lack of consensus or > otherwise. No, this is ridiculous, because the notion that "no BIP will be rejected on grounds of controversy, disagreement, lack of consensus, or otherwise," is clearly an attempt to do away with consensus models of business, and it is also not a very logical statement because controversy and disagreement are a natural part of... coming to what eventually is an agreement. >=20 > * In case of rejection, the maintainer will provide a clear, > specific list of actionable steps the BIP author can take next. For > example, a list of what changes would address the technical > objections raised. This above section I agree with. In case the maintainer believes no change could ever make > the BIP acceptable, the list must consist of instructions for how > to create a patch set and, in the case of changes to the consensus=20 > rules, how to initiate a hard fork. This above section I do not agree with because of the obvious bias in favor of the hard fork. Everything here seems to be aligned to push for hard fork, hard fork, hard fork. It's like the author can't tear his mind off it. >=20 > A BIP, even once rejected, may live on in the BIPS repository, > though its entry in the index may be sorted below others. The BIP > author may update the BIP with a summary of any resulting > discussion. As such a summary may be inherently contentious in case > of a dispute, the authors wording of that summary is final and may > not be subject to meta-debate. >=20 >=20 This doesn't seem right at all. >=20 >=20 > ---------------------------------------------------------------------- - -------- > >=20 >=20 >=20 > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net=20 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 - --=20 http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ 0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464 yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ KcBTSpDAtCxvfkwtr3DS6LtCzXcej974NW068n/92zZIKzsdcZk/o3O5ZxEO7Wg=3D =3DYwvU -----END PGP SIGNATURE-----