Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 36AA1C002A for ; 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 ; 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 ; 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 ; 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 From: alicexbt Message-ID: In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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