path: root/86/a74b384662a94f1dfb0c3c74d2b76627677874

Return-Path: <lists@achow101.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C81B9C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:44:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8F25B40374
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:44:26 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8F25B40374
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=achow101.com header.i=@achow101.com header.a=rsa-sha256
 header.s=protonmail header.b=dnHvCpal
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, 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 BXrm0FRdL1HL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:44:24 +0000 (UTC)
X-Greylist: delayed 00:10:40 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 902F24018F
Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 902F24018F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Apr 2023 21:44:23 +0000 (UTC)
Date: Wed, 19 Apr 2023 21:33:33 +0000
Authentication-Results: mail-4321.protonmail.ch;
 dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com
 header.b="dnHvCpal"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
 s=protonmail; t=1681940020; x=1682199220;
 bh=eEwmlgF/HyiPfkfQbxgv2SgGoNEYUxvw2v/D7rydLRc=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=dnHvCpalvs9dV031rlR9citE/QRCEcNwDJtao6TNINF6/6ROISPyXzeKQ5Wada8MP
 oJJRdETFZLQO13xPzY39AHj+SJY9g+Oij/E/2K+POiEbEwdST0sN9yHMwYi3TBUJ7+
 hLyMbyaddKWV0Vg44JMjv9zwNTGeyefm3nIRTXSdQpOr2Z6pKnGbAj0yNUeuMcF2WT
 N9MHqJVoSLR6wYf7KQXSJGokrM12D7eiicDU9Iq0qJFpzJDWH4ZU4LEoeceHZ+AwL/
 zmCMLhf0idT4tqyYCRNhDBmWRFqtVK8pQecYQQDvIC55ouAaHt27QyhzJPPo4yqxYG
 CI0GXYJl0s0ow==
To: bitcoin-dev@lists.linuxfoundation.org
From: Andrew Chow <lists@achow101.com>
Message-ID: <feef7f88-b46d-7355-1716-122afc6359ee@achow101.com>
In-Reply-To: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
Feedback-ID: 53660394: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:16 +0000
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:44:26 -0000

Responses in-line.
Note that the opinions expressed in this email are my own and are not
representative of what other maintainers think or believe.

On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
 >
 > Communication has been a challenge on Bitcoin Core for what I can
tell the entire history of the project. Maintainers merge a pull request
and provide no commentary on why they=E2=80=99ve merged it.

What commentary does there need to be?
It's self evident that the maintainer believes the code is ready to be
merged, and has observed enough ACKs from contributors that they are
comfortable to do so.
You're welcome to ask for clarification, but frankly, I don't think
having any commentary on merges is going to be helpful or more elaborate
in any way.
Requiring maintainers to have to write explanations for every single
merge is simply going to increase the burden on them and increase the
rate of burnout and resignations.
We've had too many maintainers step down already.
It'll end up being a bunch of boilerplate comments that don't say
anything meaningful.

There are certainly situations where PRs are merged very quickly or with
otherwise little apparent review.
But, as I said, if you ask a maintainer why it was merged, the answer
will be "I thought it was ready and had enough review".
There may be other reasons that made the maintainer think it was ready
sooner, such as the PR fixes a critical bug or security vulnerability,
but these reasons aren't going to be stated publicly.

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

There are currently 320 open PRs and 366 open issues.
I wake up every morning to 150+ email notifications containing
everything that went on overnight, and throughout the day, I typically
get hundreds more.
It's impossible to keep up with everything that goes on throughout the repo=
.
ACKs come in sporadically, PRs are updated, reviews are posted, etc.
Often times PRs are not merged simply because the maintainers were not
aware that a PR was ready to be merged.
Things can simply fall through the cracks.

Of course there are other reasons why something might not be merged, and
these generally fall into the camp of "I don't think it has had enough
review".
It's the maintainer's judgement call to make as to whether something has
been sufficiently reviewed, and part of the judgement call is to
consider the quality and competence of the reviewers.
If a PR had 100 ACKs but all from random people who have never
contributed to the project in any capacity, then it's not going to be
merged because those reviewers would be considered low quality.
It's not just about the numbers, but also about whether the reviewers
are people the maintainers think are familiar enough with an area and
have had a history of thoroughly reviewing PRs.
For example, if a reviewer who primarily works on the mempool reviewed a
PR in the wallet, I would consider their review and ACK with less weight
because they are unlikely to be familiar with the intricacies of the wallet=
.
Obviously that changes over time as they make more reviews.
For another example, if I see an ACK from a reviewer who posts reviews
that primarily contain nits on code style and other trivialities, I
would consider that ACK with less weight.

Furthermore, the maintainers are not necessarily the ones who block a merge=
.
Part of evaluating if something is ready to be merged is to read the
comments on a PR.
Other frequent contributors may have commented or asked questions that
haven't been resolved yet.
PRs will often not be merged (even if they have ACKs) until a maintainer
deems that those comments and questions have been sufficiently resolved,
typically with the commenter stating in some way that their concerns
were addressed.
In these situations, no commentary from maintainers is given nor
necessary as it should be self evident (by reading the comments) that
something is controversial.
These kinds of comments are not explicit NACKs (so someone who is only
counting (N)ACKs won't see them), but are blocking nonetheless.

Lastly, personally I like to review every PR before I merge it.
This often means that a PR that might otherwise be ready to be merged
wouldn't be merged by myself as I may not be familiar with that part of
the codebase.
It may also mean that I would require more or specific additional people
to review a PR before I merge it as I would weight my own review less
heavily.
With several long time maintainers stepping away, this may be a factor
in PRs taking longer to get merged as the remaining maintainers may be
less familiar with the parts of the codebase that were previously
maintained by someone else.

 > but a casual observer would have only seen Concept ACKs and ACKs with
3 stray NACKs. Many of these casual observers inflated the numbers on
the utxos.org site [4] signalling support for a soft fork activation
attempt.

Anyone who thinks that maintainers only look at the numbers of (N)ACKs
is delusional.
As I explained above, there is a whole lot more nuance to determining
even just the status of the opinions on a PR, nevermind the code itself.

In this specific example of a soft fork, there is also consideration of
the opinions outside of the repo itself, such as on this mailing list
and elsewhere that people discuss soft forks.

On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
 > While some simple changes can allow bitcoin to surpass ethereum, as
usual, like "Allow several OP_RETURN in one tx and no limited size"
https://github.com/bitcoin/bitcoin/issues/27043
 >
 > How long it will take remains mysterious

No one (maintainers or contributors) is obligated to implement anything.
A feature request not being implemented is because the people who do
open PRs are either not interested in implementing the feature, or are
working on other things that they believe to be higher priority.
If there is a feature that you want, then you will often need to either
to it yourself, or pay someone to do it for you.

Additionally, a feature may seem like a good idea to you, but there are
often interactions with other things that may end up resulting in it
being rejected or need significant revision, especially for something
which affects transaction relay.



Andrew Chow