summaryrefslogtreecommitdiff
path: root/b5/393a3c2d9dfba10fc5c1dce1248551a86fc97b
blob: 6d782636e412554bca057d9cbd79a4c1a4a9199d (plain)
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
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18D0AC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E0F8F60B5C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E0F8F60B5C
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=Wp0bOHKb
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tvO1G-RoEK76
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AA81E60073
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by smtp3.osuosl.org (Postfix) with ESMTPS id AA81E60073
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:13:37 +0000 (UTC)
Date: Wed, 19 Apr 2023 21:13:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1681938814; x=1682198014;
 bh=wqNsH1VKKM/pKPN3r7gTfBX0oORlhYjv/jwUMgzaUlE=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=Wp0bOHKba0FuOX3MkhwTOJvjyjWNYIc/yXR2wU86hbL4Y44pkk7tBotVpoU2X3lz8
 rcDCmg2N5YwczTijDsc2t/3W+1+lfopnsVj9xtaXv7TVcwrkyz+NdeGdrsb7gMmWhT
 WZrTf+Og6jGU5kE9YKLye3QFfPqkAQx+f+SU9Yj9qU2CUtApqZouu4T6ZnsMAhOLuY
 qDu18MHl7O2vu3drvv8M5ZerCRByWAr0EpeJkLyJaVL8xbbg7BX3+4C/rfR4X9vJJV
 30nux3lFR0GAHQtw5tjjWIfO1QBnnDvaKBrwSmhAIOMtJ+gD/+TiQam3SYlSwWi0/d
 6rdfHDBwrPg5g==
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <ZNeHbwF5IGr6p142QqLON7L2Qvt2H0fLHr-nczawVUTQMtHXTtNRWspC-9Lsp6xtjuNC5ZewHD7xaMJnzsYVRUWSMQRjaxBknfsy3-jGsPQ=@protonmail.com>
In-Reply-To: <nA4t0JwOs8yCz3Io6CHunt4VEVKRcmjhYz8Lt-v0O0upC0NT4G7VGN6OcdJfp4pw2eqZEmipXxhLLgJ5PUqbF9k_r41MTtdc9OCZF6YdgRQ=@protonmail.com>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <BAQJaPAUBbUwqKc5cf1jnO5LYij-gRKMrWHtc_wog7QUUrjxPwzXnIoegql7xsPhpUJXpRdBMwxdmlBt75k8aRT1NJVGLuhH7ZwpWmW8PU8=@protonmail.com>
 <nA4t0JwOs8yCz3Io6CHunt4VEVKRcmjhYz8Lt-v0O0upC0NT4G7VGN6OcdJfp4pw2eqZEmipXxhLLgJ5PUqbF9k_r41MTtdc9OCZF6YdgRQ=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 20 Apr 2023 00:44:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Wed, 19 Apr 2023 21:13:40 -0000

Hi Michael,

I will share something even though you didn't let me write things on severa=
l occasions on github, twitter etc.

Try this:

- As Gloria said (respect people you don't like and shared something agains=
t), create a competition for Brink. Fund bitcoin developers.
- Do more reviews personally and devs you train even if they are neglected.
- Acknowledge some reviewer know more than you. Try to learn and test thing=
s.
- After some time you will achieve the power you crave.

Its not possible to satisfy everyone even if you were bitcoin core maintain=
er now, some people would have issues. Closing a pull request hurt more so =
I respect them if they kept open something.

Note: Do not disrespect people who are new and say something. Do not try to=
 harass them. Do not try to be boss.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, April 19th, 2023 at 7:03 PM, Michael Folkson <michaelfolkson@=
protonmail.com> wrote:


> Hi alicexbt
>=20
> > I don't think commentary is required for each pull request that gets me=
rged with enough reviews, ACKs and no controversy.
>=20
>=20
> The problem is defining what is "enough". "Enough" is determined by the q=
uality of the review, the expertise of the reviewer(s), the complexity of t=
he pull request and most importantly what risks a merge of the pull request=
 poses. When there is zero communication on merge decisions (both merging a=
nd not merging over a long period of time) it creates frustration and worse=
 vacuums and soft fork activation chaos. It is a complete black box. The va=
st majority of merge decisions are uncontroversial but it would still be ni=
ce to have a comment saying something like:
>=20
> "This pull request only has 2 ACKs but it is low risk, relatively simple =
and is unlikely to be reviewed by anybody else in the near term"
>=20
> "This pull request is a consensus change, extremely high risk and is unli=
kely to be merged in the near term"
>=20
> On the rare occasions when merge decisions are controversial communicatio=
n becomes a lot more important. If some maintainers aren't responsive on IR=
C and refuse to discuss merge decisions what can we expect in future? We wa=
ke up one day, a contentious consensus change has been merged with little r=
eview in advance of a release window and the maintainer won't discuss why t=
hey have merged it. This isn't a toy anymore, it is supporting hundreds of =
billions of dollars of value and could end up supporting a lot more. It is =
surely completely unreasonable to let maintainers merge or not merge whatev=
er they like with no explanation and no willingness to discuss their merge =
decisions.
>=20
> > So I'll add that if you wish to have more decentralization in Bitcoin C=
ore funding, you can start by creating a nonprofit, gathering donations, an=
d funding somebody who works on Bitcoin Core."
>=20
>=20
> As I responded on the pull request if any long term contributor from this=
 alternative nonprofit is blocked from being a maintainer and current maint=
ainers refuse to discuss merge decisions it is irrelevant. To contribute yo=
u need a maintainer to merge your pull request(s) and to spend your review =
time wisely you need to know what pull request(s) could viably be merged by=
 a maintainer. Otherwise you're just wasting your time. We not only have op=
acity on merge decisions for normal pull requests (e.g. code) we also now h=
ave opacity on decisions for the addition of new maintainers. I was always =
under the impression that any long term contributor who demonstrated over t=
ime that they were sufficiently competent, qualified and able to contribute=
 both through opening pull requests and reviewing other people's pull reque=
sts could become a maintainer. To me and many others (until it was blocked =
by two maintainers for 5 months) Vasil met this criteria. This not only imp=
acts Vasil's and others' commitment to the project but it impacts what pull=
 requests are ultimately reviewed and merged. What is the point of spending=
 time opening or reviewing a pull request if the current maintainers won't =
look at it or are unqualified to review it and hence won't merge it?
>=20
> Gloria's advice effectively boils down to spend months setting up a non-p=
rofit, spend years becoming a long term contributor to the project and then=
 you can have the honor of being blocked from becoming a maintainer and hav=
e your contributions stunted by the current maintainers with no recourse or=
 ability to discuss their merge decisions. So yeah thanks for repeating tha=
t advice but I'm sure most would rather pass and do something else.
>=20
> Thanks
> Michael
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>=20
>=20
> ------- Original Message -------
> On Wednesday, April 19th, 2023 at 13:24, alicexbt alicexbt@protonmail.com=
 wrote:
>=20
>=20
>=20
> > Hi Michael,
> >=20
> > I was initially sad about the politics in Vasil's pull request, written=
 about it and also tried to document the process. Still think he deserves t=
o be a maintainer. Although I have some counter arguments:
> >=20
> > > Maintainers merge a pull request and provide no commentary on why the=
y=E2=80=99ve merged it.
> >=20
> > I don't think commentary is required for each pull request that gets me=
rged with enough reviews, ACKs and no controversy.
> >=20
> > > Maintainers leave a pull request with many ACKs and few (if any) NACK=
s for months and provide no commentary on why they haven't merged it
> >=20
> > This could be considered normal in pull requests that involve code chan=
ges.
> >=20
> > > The difference between say previous maintainers like Wladimir and som=
e of the current maintainers is that previous maintainers were extremely re=
sponsive on IRC.
> >=20
> > Unfair to expect every human to behave the same or work similarly. Some=
times the unresponsiveness could be to avoid controversies and heated debat=
es that go off-topic.
> >=20
> > > One farcical recent example 0 was the pull request to add Vasil Dimov=
 as a maintainer where despite many ACKs from other maintainers and other l=
ong term contributors two maintainers (fanquake and Gloria) refused to disc=
uss it on the pull request or on IRC. It took almost 5 months for Gloria to=
 comment on the pull request despite many requests from me on the PR and on=
 IRC. I even requested that they attend the weekly Core Dev IRC meeting to =
discuss it which they didn=E2=80=99t attend.
> >=20
> > - Maintainers should be free to avoid involvement in a pull request. As=
 long as a subset of maintainers have an opinion on the pull request, thing=
s should be fine.
> > - I agree with Gloria's comment: "I had not NACKed this either because =
my opinion could change over time, NACKs are sometimes needlessly interpret=
ed as personal attacks, and Brink has been antagonized on Twitter each time=
 multiple grantees have similar opinions about this. So I'll add that if yo=
u wish to have more decentralization in Bitcoin Core funding, you can start=
 by creating a nonprofit, gathering donations, and funding somebody who wor=
ks on Bitcoin Core." Last part of this comment also solves the problem shar=
ed in other thread related to new bitcoin implementation. Brink needs some =
competition and bitcoin core needs more reviewers.
> > - I also agree with Andrew's comment: "frankly, I think opinions aren't=
 being shared because of potential backlash from aggressive users such as y=
ourself and bytes1440000"
> >=20
> > > Maintainers and long term contributors (if they commented at all) wer=
e gently enthusiastic (Concept ACKing etc) without ACKing that it was ready=
 to merge. A long term observer of the Core repo would have known that it w=
asn=E2=80=99t ready to merge or ready to attempt to activate (especially gi=
ven it was a consensus change) but a casual observer would have only seen C=
oncept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inf=
lated the numbers on the utxos.org site 4 signalling support for a soft for=
k activation attempt.
> >=20
> > - I don't see anything wrong with sharing honest opinion if someone agr=
ees with the concept. It does not make a pull request ready to get merged.
> > - utxos.org is an external site maintained by Jeremy with opinions on B=
IP 119. Everyone is free to maintain such lists and I think you had also cr=
eated one as GitHub gist.
> >=20
> > > I will probably write about bitcoin-inquisition/default signet in a f=
uture email as I do think the perception that it is =E2=80=9Cthe one and on=
ly=E2=80=9D staging ground for consensus changes is dangerous 6 if the main=
tainer(s) on that project have the same inclinations as a subset of the Cor=
e maintainers.
> >=20
> > This perception (if exists) can be killed by creating a custom signet, =
maintaining it differently, get more reviews, testing and share details wit=
h community regularly.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-138165456=
4
> > 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > ------- Original Message -------
> > On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > Communication has been a challenge on Bitcoin Core for what I can tel=
l the entire history of the project. Maintainers merge a pull request and p=
rovide no commentary on why they=E2=80=99ve merged it. Maintainers leave a =
pull request with many ACKs and few (if any) NACKs for months and provide n=
o commentary on why they haven't merged it. I can only speculate on why and=
 it probably depends on the individual maintainer. Sometimes it will be poo=
r communication skills, sometimes it will be a desire to avoid accountabili=
ty, sometimes it will be fear of unreasonable and spiteful legal action if =
they mistakenly merge a pull request that ends up containing a bug. But sea=
rch through the pull requests on Bitcoin Core and you will rarely see a rat=
ionale for a merge decision. The difference between say previous maintainer=
s like Wladimir and some of the current maintainers is that previous mainta=
iners were extremely responsive on IRC. If you disagreed with a merge decis=
ion or thought it had been merged prematurely they would be happy to discus=
s it on IRC. In present times at least a subset of the current maintainers =
are not responsive on IRC and will refuse to discuss a merge decision. One =
farcical recent example 0 was the pull request to add Vasil Dimov as a main=
tainer where despite many ACKs from other maintainers and other long term c=
ontributors two maintainers (fanquake and Gloria) refused to discuss it on =
the pull request or on IRC. It took almost 5 months for Gloria to comment o=
n the pull request despite many requests from me on the PR and on IRC. I ev=
en requested that they attend the weekly Core Dev IRC meeting to discuss it=
 which they didn=E2=80=99t attend.
> > >=20
> > > A pull request to add a maintainer isn=E2=80=99t a normal pull reques=
t. Generally pull requests contain a lot more lines of code than a single l=
ine adding a trusted key. Not merging a pull request for a long period of t=
ime can be extremely frustrating for a pull request author especially when =
maintainers and long term contributors don=E2=80=99t comment on the pull re=
quest and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clear=
ly it is the lesser evil when compared to merging a harmful or bug ridden p=
ull request but poor non-existent communication is not the only way to prev=
ent this. Indeed it creates as many problems as it solves.
> > >=20
> > > Another farcical recent(ish) example was the CTV pull request 1 that =
ultimately led to a contentious soft fork activation attempt that was calle=
d off at the last minute. If you look at the comments on the pull request t=
here were 3 individuals (including myself) who NACKed the pull request and =
I think it is fair to say that none of us would be considered long term con=
tributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times fo=
r continuing to pursue a soft fork activation attempt when it was clear it =
was contentious 3 but if you look at the pull request comments it certainly=
 isn=E2=80=99t clear it was. Maintainers and long term contributors (if the=
y commented at all) were gently enthusiastic (Concept ACKing etc) without A=
CKing that it was ready to merge. A long term observer of the Core repo wou=
ld have known that it wasn=E2=80=99t ready to merge or ready to attempt to =
activate (especially given it was a consensus change) but a casual observer=
 would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of the=
se casual observers inflated the numbers on the utxos.org site 4 signalling=
 support for a soft fork activation attempt.
> > >=20
> > > I set out originally to write about the controls and processes around=
 merges on the default signet (bitcoin-inquisition 5) but it quickly became=
 obvious to me that if communication around Core merges/non-merges is this =
weak you can hardly expect it to be any better on bitcoin-inquisition/defau=
lt signet where there is no real monetary value at stake. I will probably w=
rite about bitcoin-inquisition/default signet in a future email as I do thi=
nk the perception that it is =E2=80=9Cthe one and only=E2=80=9D staging gro=
und for consensus changes is dangerous 6 if the maintainer(s) on that proje=
ct have the same inclinations as a subset of the Core maintainers.
> > >=20
> > > As I stated at the beginning there is an element to this which is not=
 individual(s) specific and an adverse reaction to outright malicious actor=
s external to any of these projects. I do not think any of the current main=
tainers on Core or bitcoin-inquisition are outright malicious even if a sub=
set of them consistently frustrate me with their lack of transparency and a=
ccountability. But this issue isn't going away and I'm sure we'll hear more=
 on this from others in the coming months. To me it is a straight choice of=
 taking transparency and accountability much more seriously or failing that=
 investing more heavily (time and resources) in consensus compatible forks =
of Core and treating Core like it is a proprietary "open source" project wh=
ere merge decisions are not explained or justified in the open.
> > >=20
> > > --
> > > Michael Folkson
> > > Email: michaelfolkson at protonmail.com
> > > Keybase: michaelfolkson
> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3