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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z5WcS-000534-Go
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 10:00:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.182 as permitted sender)
client-ip=209.85.212.182; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f182.google.com;
Received: from mail-wi0-f182.google.com ([209.85.212.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5WcR-0006ip-7q
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 10:00:24 +0000
Received: by wicnd19 with SMTP id nd19so55138648wic.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 03:00:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.209.130 with SMTP id mm2mr13882301wjc.64.1434621617236;
Thu, 18 Jun 2015 03:00:17 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 03:00:17 -0700 (PDT)
In-Reply-To: <55828737.6000007@riseup.net>
References: <55828737.6000007@riseup.net>
Date: Thu, 18 Jun 2015 12:00:17 +0200
X-Google-Sender-Auth: 6uhhfKil_MX3DsC4mZ231cLS_h4
Message-ID: <CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: odinn <odinn.cyberguerrilla@riseup.net>
Content-Type: multipart/alternative; boundary=047d7b3a82e2e1ef050518c7df05
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: 1Z5WcR-0006ip-7q
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 10:00:24 -0000
--047d7b3a82e2e1ef050518c7df05
Content-Type: text/plain; charset=UTF-8
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.
--047d7b3a82e2e1ef050518c7df05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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.<div><br></div><div>So why did I =
say it? Because it's consistent with what I've always said: =C2=A0y=
ou cannot run a codebase like Wikipedia. Maintainers have to take part in d=
ebates, and then make a decision, and anyone else who was delegated commit =
access for robustness or convenience must then respect that decision. It=
9;s the only way to keep a project making progress at a reasonable pace.</d=
iv><div><br></div><div>This is not a radical position. That's how nearl=
y all coding projects work. I have been involved with open source for 15 ye=
ars and the 'single maintainer who makes decisions' model is normal=
, even if in some large codebases =C2=A0subsystems have delegated submainta=
iners.</div><div><br></div><div>This is also how all my own projects are ru=
n. Bitcoinj has multiple people with commit access. Regardless, if there we=
re to be some design dispute or whatever, I wouldn't tolerate the other=
s 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 peopl=
e's projects by threatening to revert the maintainers changes.</div><di=
v><br></div><div>Core is in the weird position where there's no decisio=
n making ability at all, because anyone who shows up and shouts enough can =
generate 'controversy', then Wladimir sees there is disagreement an=
d won't touch the issue in question. So it just runs and runs and <i>an=
yone</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 dec=
ision making. I disagree. It leads to no decision making, which is not the =
same thing at all.</div></div>
--047d7b3a82e2e1ef050518c7df05--
|
