Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 18D0AC002A for ; 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 ; 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 ; 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 ; 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 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: Thu, 20 Apr 2023 00:44:37 +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 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 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