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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z5cKL-0003I1-B7
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 16:06:05 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.176 as permitted sender)
client-ip=209.85.212.176; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f176.google.com;
Received: from mail-wi0-f176.google.com ([209.85.212.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5cKK-00064Z-4v
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 16:06:05 +0000
Received: by wiga1 with SMTP id a1so176046061wig.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 09:05:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.11.193 with SMTP id ek1mr29460547wid.15.1434643558201;
Thu, 18 Jun 2015 09:05:58 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 09:05:58 -0700 (PDT)
In-Reply-To: <20150618154640.GA7840@amethyst.visucore.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
<CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com>
<5582E3FE.7010206@bitcoins.info>
<20150618154640.GA7840@amethyst.visucore.com>
Date: Thu, 18 Jun 2015 18:05:58 +0200
X-Google-Sender-Auth: F27AYOalZTo9uBqQ1bE8kvChLKo
Message-ID: <CANEZrP016FjDZx9cNMbPR5nV0BRVxBCf-GEfD+59JseJcNWjvA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043bdedaaa7e960518ccfbad
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5cKK-00064Z-4v
Cc: g@amethyst.visucore.com,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 16:06:05 -0000
--f46d043bdedaaa7e960518ccfbad
Content-Type: text/plain; charset=UTF-8
>
> So then: make a proposal for a better process, post it to this list.
>
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.
The following section applies to BIPs that affect the block chain consensus
rules or the peer to peer protocol and thus require changes to Bitcoin
Core.
Once a draft BIP has been submitted to bitcoin-development for
consideration, the Bitcoin Core maintainer will deliver a preliminary
yes/no verdict within three weeks. 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.
The verdict will meet the following criteria:
- It will address the latest version of the BIP at the time the verdict
is rendered.
- 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.
- 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. 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 rules, how to initiate a hard fork.
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.
--f46d043bdedaaa7e960518ccfbad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">So then: make a proposal for a better process, post it to this=
list.<br></blockquote><div><br></div><div>Alright. Here is a first cut of =
my proposal. It can be inserted into an amended BIP 1 after "What belo=
ngs in a successful BIP?". Let me know what you think.</div><div><br><=
/div><div><br></div><div><br></div><div>The following section applies to BI=
Ps that affect the block chain consensus rules or the peer to peer protocol=
and thus require changes to Bitcoin Core.=C2=A0</div><div><br></div><div>O=
nce a draft BIP has been submitted to bitcoin-development for consideration=
, the Bitcoin Core maintainer will deliver a preliminary yes/no verdict wit=
hin three weeks. 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 t=
ime.</div><div><br></div><div>The verdict will meet the following criteria:=
</div><div><ul><li>It will address the latest version of the BIP at the tim=
e the verdict is rendered.<br><br></li><li>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 mainta=
iner agrees with a technical point made during discussion, he must own that=
opinion for himself. Therefore no BIP will be rejected on grounds of contr=
oversy, disagreement, lack of consensus or otherwise.<br><br></li><li>In ca=
se of rejection, the maintainer will provide a clear, specific list of acti=
onable steps the BIP author can take next. For example, a list of what chan=
ges would address the technical objections raised. In case the maintainer b=
elieves 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 rules, how to initiate a hard fork.<br></li></ul><div>A BI=
P, 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 inher=
ently contentious in case of a dispute, the authors wording of that summary=
is final and may not be subject to meta-debate.</div></div><div><br></div>=
<div><br></div></div></div></div>
--f46d043bdedaaa7e960518ccfbad--
|
