path: root/ab/0eb954148a5b817dd52af6683cf429128c8fd3

Return-Path: <alicexbt@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 36AA1C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 12:24:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 11F9140453
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 12:24:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 11F9140453
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=f/mT0TQl
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BL46q6c6rZ_4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 12:24:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AC9F4400FB
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp2.osuosl.org (Postfix) with ESMTPS id AC9F4400FB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 12:24:28 +0000 (UTC)
Date: Wed, 19 Apr 2023 12:24:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1681907066; x=1682166266;
 bh=oS2uZ+nSubVsqT1GrZbYFf2eUsG5PAboqqFA5QuqaPo=;
 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=f/mT0TQlgxvofz1Nl+MFBt+qNyolUxpQR2nQ4lnGusppqmcZ3PTjDm7zrOwYENj2C
 unDnbp0E8rx6pX/a7JUrlb68PMTbtIVessnl2VlLM46lCT96ZMy8FbRZkfWrC7CtzD
 nuuBvKLV/GwMXRF7QVutWLpMhFH7U1fqHR1uGY+BP4RCkuWy+XG4VQ9cKlGHXLo3fQ
 jlWMJYEvUuTFBY1HofHcVSb576fxBq0YKFCEZsDOIjK/xwfwOQ97sjTKsh3+BfyEmS
 LRX1C7+NtwqRAxrXpRlpfYloVWGcaGh6V09A7yKJI6v1ChkkCVHVGC7JgNhbrieL9H
 fJEOSMVlEzW4w==
To: Michael Folkson <michaelfolkson@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <BAQJaPAUBbUwqKc5cf1jnO5LYij-gRKMrWHtc_wog7QUUrjxPwzXnIoegql7xsPhpUJXpRdBMwxdmlBt75k8aRT1NJVGLuhH7ZwpWmW8PU8=@protonmail.com>
In-Reply-To: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@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: Wed, 19 Apr 2023 13:44:30 +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 12:24:30 -0000

Hi Michael,

I was initially sad about the politics in Vasil's pull request, written abo=
ut it and also tried to document the process. Still think he deserves to be=
 a maintainer. Although I have some counter arguments:

> Maintainers merge a pull request and provide no commentary on why they=
=E2=80=99ve merged it.

I don't think commentary is required for each pull request that gets merged=
 with enough reviews, ACKs and no controversy.

> Maintainers leave a pull request with many ACKs and few (if any) NACKs fo=
r months and provide no commentary on why they haven't merged it

This could be considered normal in pull requests that involve code changes.

> The difference between say previous maintainers like Wladimir and some of=
 the current maintainers is that previous maintainers were extremely respon=
sive on IRC.

Unfair to expect every human to behave the same or work similarly. Sometime=
s the unresponsiveness could be to avoid controversies and heated debates t=
hat go off-topic.

> One farcical recent example [0] was the pull request to add Vasil Dimov a=
s a maintainer where despite many ACKs from other maintainers and other lon=
g term contributors two maintainers (fanquake and Gloria) refused to discus=
s it on the pull request or on IRC. It took almost 5 months for Gloria to c=
omment on the pull request despite many requests from me on the PR and on I=
RC. I even requested that they attend the weekly Core Dev IRC meeting to di=
scuss it which they didn=E2=80=99t attend.

- Maintainers should be free to avoid involvement in a pull request. As lon=
g as a subset of maintainers have an opinion on the pull request, things sh=
ould be fine.=20
- I agree with Gloria's [comment][0]: "I had not NACKed this either because=
 my opinion could change over time, NACKs are sometimes needlessly interpre=
ted as personal attacks, and Brink has been antagonized on Twitter each tim=
e multiple grantees have similar opinions about this. So I'll add that if y=
ou wish to have more decentralization in Bitcoin Core funding, you can star=
t by creating a nonprofit, gathering donations, and funding somebody who wo=
rks on Bitcoin Core." Last part of this comment also solves the problem sha=
red in other thread related to new bitcoin implementation. Brink needs some=
 competition and bitcoin core needs more reviewers.=20
- I also agree with Andrew's [comment][1]: "frankly, I think opinions aren'=
t being shared because of potential backlash from aggressive users such as =
yourself and bytes1440000"

> Maintainers and long term contributors (if they commented at all) were ge=
ntly 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 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 Conc=
ept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflat=
ed the numbers on the utxos.org site [4] signalling support for a soft fork=
 activation attempt.

- I don't see anything wrong with sharing honest opinion if someone agrees =
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 BIP 1=
19. Everyone is free to maintain such lists and I think you had also create=
d one as GitHub gist.

>  I will probably write about bitcoin-inquisition/default signet in a futu=
re email as I do think the perception that it is =E2=80=9Cthe one and only=
=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.

This perception (if exists) can be killed by creating a custom signet, main=
taining it differently, get more reviews, testing and share details with co=
mmunity regularly.

/dev/fd0
floppy disk guy

[0]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
[1]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748


Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev <b=
itcoin-dev@lists.linuxfoundation.org> wrote:


> Communication has been a challenge on Bitcoin Core for what I can tell th=
e entire history of the project. Maintainers merge a pull request and provi=
de 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 no co=
mmentary 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 poor co=
mmunication skills, sometimes it will be a desire to avoid accountability, =
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 search =
through the pull requests on Bitcoin Core and you will rarely see a rationa=
le for a merge decision. The difference between say previous maintainers li=
ke Wladimir and some of the current maintainers is that previous maintainer=
s were extremely responsive on IRC. If you disagreed with a merge decision =
or thought it had been merged prematurely they would be happy to discuss 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 farc=
ical recent example [0] was the pull request to add Vasil Dimov as a mainta=
iner where despite many ACKs from other maintainers and other long term con=
tributors two maintainers (fanquake and Gloria) refused to discuss it on th=
e 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 w=
hich they didn=E2=80=99t attend.
>=20
>=20
>=20
> A pull request to add a maintainer isn=E2=80=99t a normal pull request. G=
enerally pull requests contain a lot more lines of code than a single line =
adding a trusted key. Not merging a pull request for a long period of time =
can be extremely frustrating for a pull request author especially when main=
tainers and long term contributors don=E2=80=99t comment on the pull reques=
t and the pull request is stuck in =E2=80=9Crebase hell=E2=80=9D. Clearly i=
t is the lesser evil when compared to merging a harmful or bug ridden pull =
request but poor non-existent communication is not the only way to prevent =
this. Indeed it creates as many problems as it solves.
>=20
>=20
>=20
> Another farcical recent(ish) example was the CTV pull request [1] that ul=
timately led to a contentious soft fork activation attempt that was called =
off at the last minute. If you look at the comments on the pull request the=
re 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 contr=
ibutors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for =
continuing to pursue a soft fork activation attempt when it was clear it wa=
s 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] signalli=
ng support for a soft fork activation attempt.
>=20
>=20
>=20
> I set out originally to write about the controls and processes around mer=
ges on the default signet (bitcoin-inquisition [5]) but it quickly became o=
bvious to me that if communication around Core merges/non-merges is this we=
ak you can hardly expect it to be any better on bitcoin-inquisition/default=
 signet where there is no real monetary value at stake. I will probably wri=
te about bitcoin-inquisition/default signet in a future email as I do think=
 the perception that it is =E2=80=9Cthe one and only=E2=80=9D staging groun=
d 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.=C2=A0
>=20
>=20
>=20
> As I stated at the beginning there is an element to this which is not ind=
ividual(s) specific and an adverse reaction to outright malicious actors ex=
ternal to any of these projects. I do not think any of the current maintain=
ers on Core or bitcoin-inquisition are outright malicious even if a subset =
of them consistently frustrate me with their lack of transparency and accou=
ntability.=C2=A0But this issue isn't going away and I'm sure we'll hear mor=
e on this from others in the coming months. To me it is a straight choice o=
f taking transparency and accountability much more seriously or failing tha=
t investing more heavily (time and resources) in consensus compatible forks=
 of Core and treating Core like it is a proprietary "open source" project w=
here merge decisions are not explained or justified in the open.
>=20
>=20
>=20
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>=20
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>=20
> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/0=
20386.html
>=20
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b=
718
>=20
> [4]: https://utxos.org/signals/
>=20
> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septemb=
er/020921.html
>=20
> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Septemb=
er/020948.html
>=20
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3