diff options
| author | Luke Dashjr <luke@dashjr.org> | 2016-02-02 07:54:29 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-02 07:56:00 +0000 |
| commit | f60679aa2b29488d67619fc60a35c05ec77c634e (patch) | |
| tree | 8fcc0ac1880329f1809786399081301e13f9f980 | |
| parent | 0f5a1e98e7204cbb23ec3dabe178df8f3eb28b9d (diff) | |
| download | pi-bitcoindev-f60679aa2b29488d67619fc60a35c05ec77c634e.tar.gz pi-bitcoindev-f60679aa2b29488d67619fc60a35c05ec77c634e.zip | |
Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
| -rw-r--r-- | dc/69eda23a4682571436a9ae980e1507e541578f | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/dc/69eda23a4682571436a9ae980e1507e541578f b/dc/69eda23a4682571436a9ae980e1507e541578f new file mode 100644 index 000000000..2cc3290a7 --- /dev/null +++ b/dc/69eda23a4682571436a9ae980e1507e541578f @@ -0,0 +1,126 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 29F8DF2F + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 2 Feb 2016 07:56:00 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id A235D10C + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 2 Feb 2016 07:55:59 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id D2DF538A9783; + Tue, 2 Feb 2016 07:54:42 +0000 (UTC) +X-Hashcash: 1:25:160202:dscotese@litmocracy.com::10cEq0aRglE88Oku:a35xi +X-Hashcash: 1:25:160202:bitcoin-dev@rgrant.org::NahwDdMdVP+Kd0nS:aKzmR +X-Hashcash: 1:25:160202:bitcoin-dev@lists.linuxfoundation.org::8rwrs7bkBE/JOjqj:ePDKK +From: Luke Dashjr <luke@dashjr.org> +To: Dave Scotese <dscotese@litmocracy.com>, Ryan Grant <bitcoin-dev@rgrant.org> +Date: Tue, 2 Feb 2016 07:54:29 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; ) +References: <201602012253.18009.luke@dashjr.org> + <CAGLBAhffm+1m=DAph-ac8mA9ytLpKqTT45XG1r6UFGFoUvJ+PA@mail.gmail.com> +In-Reply-To: <CAGLBAhffm+1m=DAph-ac8mA9ytLpKqTT45XG1r6UFGFoUvJ+PA@mail.gmail.com> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201602020754.31734.luke@dashjr.org> +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_SBL, + RP_MATCHES_RCVD autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] BIP Process: Status, comments, + and copyright licenses +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 02 Feb 2016 07:56:00 -0000 + +On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote: +> The section that starts "Should two software projects need to release" +> addresses issues that are difficult to ascertain from what is written +> there. I'll take a stab at what it means: +> +> Would bitcoin be better off if multiple applications provided their own +> implementations of API/RPC and corresponding application layer BIPs? +> +> - While there is only one such application, its UI will be the obvious +> standard and confusion in usability will be avoided. +> - Any more than a single such application will benefit from the +> coordination encouraged and aided by this BIP and BIP 123. + +The original question is intended to answer both: a) why only one +implementation is insufficient for Final status, and b) why two is sufficient. + +If every application had its own BIP (how I understand your version), none of +them would be standards and it wouldn't make sense to have a BIP at all - just +project documentation would be sufficient. + +> "To avoid doubt: comments and status are unrelated metrics to judge a BIP, +> and neither should be directly influencing the other." makes more sense to +> me as "To avoid doubt: comments and status are intended to be unrelated +> metrics. Any influence of one over the other indicates a deviation from +> their intended use." This can be expanded with a simple example: "In other +> words, a BIP having the status 'Rejected' is no reason not to write +> additional comments about it. Likewise, overwhelming support for a BIP in +> its comments section doesn't change the requirements for the 'Accepted' or +> 'Active' status." + +Extending this to "influence" is probably too far - after all, comments may +discourage implementations, which can very well result in the Status +eventually becoming Rejected rather than Final. How about: + +"To avoid doubt: comments and status are intended to be unrelated metrics. In +other words, a BIP having the status 'Rejected' is no reason to write (or not +write) additional comments about it, nor would a status of 'Final' preclude +comments discouraging [further] implementation. Likewise, overwhelming support +for a BIP in its comments section doesn't change the requirements for the +'Final' or 'Active' status." + +> Since the Bitcoin Wiki can be updated with comments from other places, I +> think the author of a BIP should be allowed to specify other Internet +> locations for comments. So "link to a Bitcoin Wiki page" could instead be +> "link to a comments page (strongly recommended to be in the Bitcoin +> Wiki)". + +Hmm, I wonder if this could be too easily abuse to discourage comments +(because the commenter does not wish to register with yet another forum), +and/or censor negative comments (because the author has made his own forum +specifically for the purpose). + +On Tuesday, February 02, 2016 6:35:07 AM you wrote: +> For section "Formally defining consensus", +> +> Where objections were not deemed substantiated by the community, clear +> reasoning must be offered. + +I have integrated this into the draft. + +> For section "BIP Comments", +> +> Comments should be solicited on the bitcoin-dev mailing list, and +> summarized fairly in the wiki; with notice of summarization and time +> for suggesting edits on the mailing list. Wiki registration and +> monitoring should not be a required hurdle to participation. + +The intent is for the commenter to edit the wiki page himself. I have updated +it to reflect this. + +Luke + |