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
|
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 <mark@friedenbach.org>) id 1Z5bLn-0000AF-8t
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 15:03:31 +0000
X-ACL-Warn:
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5bLl-00084P-QW
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 15:03:31 +0000
Received: by igbzc4 with SMTP id zc4so129260297igb.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 08:03:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-type;
bh=dNnqVWfZpMsQ3Eair3fmAmZwk0mTHZMKwdF6Lc/Ztxk=;
b=KYtqX1nkq69zleAUBgJTjE9UeZV53gDDycnw3B6lKRmCsx0Z7KMHfxZ6T/K2bdG3me
VaL9qxsFGPcpgxd30gQ4r5ec7rV4q+iZdj6GVjg/hRAttIJpiwJR045DZ2gpMWEPnhML
tE++TCJJ3ymhz9Ssi0c1ZTb3+Hd/nJCt5qh3bw9NuDpD088RreREkKfgZacUnq9ogRep
9xCXGlfH46M2jxKc/rkySnpHkDli1Oyw9ioTkI65887JIs8U1s+DSsjLebjNsdCf98XY
N+WP8kpYBaSexbZkIpDIlJA+DXA2EpD7Zo6BbgQHz3RZIQgY2qXyk6p6qlWP6jwL/TZO
RnjA==
X-Gm-Message-State: ALoCoQn6o2cHy81WO73W7pQS2LnPTCZRJfi8ElFvL2odk0Wv/MsobcJKrLIU1+yrEH9NkVWU8AIh
X-Received: by 10.50.142.9 with SMTP id rs9mr18388740igb.17.1434639802222;
Thu, 18 Jun 2015 08:03:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.149.20 with HTTP; Thu, 18 Jun 2015 08:03:01 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 18 Jun 2015 08:03:01 -0700
Message-ID: <CAOG=w-sWimZTJe=4gCvC5R7SAEK+Nvo-hZtM7xC-bBQd0pG3mw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>,
Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c2ff1ccaeb380518cc1bc2
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Z5bLl-00084P-QW
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 15:03:31 -0000
--001a11c2ff1ccaeb380518cc1bc2
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <mike@plan99.net> wrote:
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>
There is a quote from United States Supreme Court Justice Potter Stewart to
describe his threshold test for obscenity which is relevant here: "I know
it when I see it."
It is hard certainly, and perhaps even impossible to write down a system of
rules that is used to resolve every dispute among core developers. But that
doesn't mean it isn't obvious to all the participants what is going on. If
a contentious change is proposed, and if after sufficient debate there are
still members of the technical community with reasoned, comprehensible
objections who are not merely being obstinate in the views -- a neutral
observer would agree that their concerns have not been met -- then there is
a lack of consensus.
If there was some sort of formal process however, the system wouldn't work.
Rules can be gamed, and if you add rules to a process then that process can
be gamed. Instead we all have a reasonable understanding of what "technical
consensus" is, and we all know it when we see it. Where we do not see it,
we do not proceed.
--001a11c2ff1ccaeb380518cc1bc2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <span dir=3D"l=
tr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.ne=
t</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote">The first issue is how =
are decisions made in Bitcoin Core? I struggle to explain this to others be=
cause I don't understand it myself. Is it a vote of people with commit =
access? Is it a 100% agreement of "core developers" and if so, wh=
o are these people? Is it "whoever reverts the change last"?=C2=
=A0 Could I write down in a document a precise description of how decisions=
are made? No, and that's been a fairly frustrating problem for a long =
time.<br></div></div></div></blockquote><div><br>There is a quote from Unit=
ed States Supreme Court Justice Potter Stewart to describe his threshold te=
st for obscenity which is relevant here: "I know it when I see it.&quo=
t;<br><br></div><div>It is hard certainly, and perhaps even impossible to w=
rite down a system of rules that is used to resolve every dispute among cor=
e developers. But that doesn't mean it isn't obvious to all the par=
ticipants what is going on. If a contentious change is proposed, and if aft=
er sufficient debate there are still members of the technical community wit=
h reasoned, comprehensible objections who are not merely being obstinate in=
the views -- a neutral observer would agree that their concerns have not b=
een met -- then there is a lack of consensus.<br><br></div><div>If there wa=
s some sort of formal process however, the system wouldn't work. Rules =
can be gamed, and if you add rules to a process then that process can be ga=
med. Instead we all have a reasonable understanding of what "technical=
consensus" is, and we all know it when we see it. Where we do not see=
it, we do not proceed.<br></div></div></div></div>
--001a11c2ff1ccaeb380518cc1bc2--
|
