1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
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
|
