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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1Z5eFi-0002em-KH
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:09:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.52 as permitted sender)
client-ip=209.85.215.52; envelope-from=melvincarvalho@gmail.com;
helo=mail-la0-f52.google.com;
Received: from mail-la0-f52.google.com ([209.85.215.52])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5eFh-0000Ar-8I
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:09:26 +0000
Received: by labbc20 with SMTP id bc20so59588676lab.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 11:09:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.126.42 with SMTP id mv10mr14370078lbb.58.1434650958814;
Thu, 18 Jun 2015 11:09:18 -0700 (PDT)
Received: by 10.112.137.99 with HTTP; Thu, 18 Jun 2015 11:09:18 -0700 (PDT)
In-Reply-To: <CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
Date: Thu, 18 Jun 2015 20:09:18 +0200
Message-ID: <CAKaEYh+FyDmN0aXNJY18yhiwRPtSVGiZiO+cMS1fRs1VnyTc2A@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c36bc6c6e61f0518ceb4af
X-Spam-Score: -0.6 (/)
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
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Z5eFh-0000Ar-8I
Cc: 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 18:09:26 -0000
--001a11c36bc6c6e61f0518ceb4af
Content-Type: text/plain; charset=UTF-8
On 18 June 2015 at 12:00, Mike Hearn <mike@plan99.net> wrote:
> Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
> already said long ago he wouldn't just commit something, even though he has
> the ability to do so.
>
> So why did I say it? Because it's consistent with what I've always said:
> you cannot run a codebase like Wikipedia. Maintainers have to take part in
> debates, and then make a decision, and anyone else who was delegated commit
> access for robustness or convenience must then respect that decision. It's
> the only way to keep a project making progress at a reasonable pace.
>
> This is not a radical position. That's how nearly all coding projects
> work. I have been involved with open source for 15 years and the 'single
> maintainer who makes decisions' model is normal, even if in some large
> codebases subsystems have delegated submaintainers.
>
> This is also how all my own projects are run. Bitcoinj has multiple people
> with commit access. Regardless, if there were to be some design dispute or
> whatever, I wouldn't tolerate the others with commit access starting some
> kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
> expect to get my own way in other people's projects by threatening to
> revert the maintainers changes.
>
> Core is in the weird position where there's no decision making ability at
> all, because anyone who shows up and shouts enough can generate
> 'controversy', then Wladimir sees there is disagreement and won't touch the
> issue in question. So it just runs and runs and *anyone* with commit
> access can then block any change.
>
> I realise some people think this anti-process leads to better decision
> making. I disagree. It leads to no decision making, which is not the same
> thing at all.
>
Bicoin is not like other projects. There are large financial stakes
involved. I was at a standards convention once and the head of standards
at a large company joked to me:
"We know there are 6 people in the standards world that we can never buy.
So we just buy everyone else".
You have to luck out in a huge way to get a person like that running your
project. Linux has done. Id say bitcoin has been lucky there too. But
have a look at other projects, have a look at the alts, the *last* thing
you want is a dictator in may cases.
Ultimately bitcoin is a ledger based on consensus. There are 3 branches,
the miners, the protocol and the market. They all play a role in
regulating bitcoin and generally on the conservative side (which I think is
a good thing). Whatever your view on the 20MB change, it's not a
*conservative* approach, which is the approach that has served bitcoin very
well so far.
So bitcoin is not like other open source projects, and that's probably
quite a good thing.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11c36bc6c6e61f0518ceb4af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 18 June 2015 at 12:00, Mike Hearn <span dir=3D"ltr"><<a href=3D"m=
ailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Dude, calm down. I d=
on't have commit access to Bitcoin Core and Gavin already said long ago=
he wouldn't just commit something, even though he has the ability to d=
o so.<div><br></div><div>So why did I say it? Because it's consistent w=
ith what I've always said: =C2=A0you cannot run a codebase like Wikiped=
ia. Maintainers have to take part in debates, and then make a decision, and=
anyone else who was delegated commit access for robustness or convenience =
must then respect that decision. It's the only way to keep a project ma=
king progress at a reasonable pace.</div><div><br></div><div>This is not a =
radical position. That's how nearly all coding projects work. I have be=
en involved with open source for 15 years and the 'single maintainer wh=
o makes decisions' model is normal, even if in some large codebases =C2=
=A0subsystems have delegated submaintainers.</div><div><br></div><div>This =
is also how all my own projects are run. Bitcoinj has multiple people with =
commit access. Regardless, if there were to be some design dispute or whate=
ver, I wouldn't tolerate the others with commit access starting some ki=
nd of Wiki-style edit war in the code if they disagreed. Nor would I ever e=
xpect to get my own way in other people's projects by threatening to re=
vert the maintainers changes.</div><div><br></div><div>Core is in the weird=
position where there's no decision making ability at all, because anyo=
ne who shows up and shouts enough can generate 'controversy', then =
Wladimir sees there is disagreement and won't touch the issue in questi=
on. So it just runs and runs and <i>anyone</i>=C2=A0with commit access can =
then block any change.</div><div><br></div><div>I realise some people think=
this anti-process leads to better decision making. I disagree. It leads to=
no decision making, which is not the same thing at all.</div></div></block=
quote><div><br></div><div>Bicoin is not like other projects.=C2=A0 There ar=
e large financial stakes involved.=C2=A0 I was at a standards convention on=
ce and the head of standards at a large company joked to me:<br><br>"W=
e know there are 6 people in the standards world that we can never buy.=C2=
=A0 So we just buy everyone else".<br><br></div><div>You have to luck =
out in a huge way to get a person like that running your project.=C2=A0 Lin=
ux has done.=C2=A0 Id say bitcoin has been lucky there too.=C2=A0 But have =
a look at other projects, have a look at the alts, the *last* thing you wan=
t is a dictator in may cases.<br><br></div><div>Ultimately bitcoin is a led=
ger based on consensus.=C2=A0 There are 3 branches, the miners, the protoco=
l and the market.=C2=A0 They all play a role in regulating bitcoin and gene=
rally on the conservative side (which I think is a good thing).=C2=A0 Whate=
ver your view on the 20MB change, it's not a *conservative* approach, w=
hich is the approach that has served bitcoin very well so far.=C2=A0 <br><b=
r></div><div>So bitcoin is not like other open source projects, and that=
9;s probably quite a good thing.<br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div>
--001a11c36bc6c6e61f0518ceb4af--
|
