path: root/0a/5f6e45283ed2c33a70c697affeee6aca542487

Return-Path: <aymeric@peersm.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C7466C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 14:25:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id A16A06FEFB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 14:25:36 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A16A06FEFB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 86kAc3nLpGX6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 14:25:34 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1B7036FEFA
Received: from 7.mo548.mail-out.ovh.net (7.mo548.mail-out.ovh.net
 [46.105.33.25])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1B7036FEFA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 14:25:33 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.4.188])
 by mo548.mail-out.ovh.net (Postfix) with ESMTPS id A23E8214A4;
 Thu, 20 Apr 2023 14:25:31 +0000 (UTC)
Received: from peersm.com (37.59.142.107) by DAG6EX2.mxp6.local (172.16.2.52)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 20 Apr
 2023 16:25:30 +0200
Authentication-Results: garm.ovh; auth=pass
 (GARM-107S0012533c719-6501-4944-ac1f-1f10a18bff76,
 5E17EACF1FF56CB846BCCF407048ED344BBC7385) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.112.152
To: Erik Aronesty <erik@q32.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <feef7f88-b46d-7355-1716-122afc6359ee@achow101.com>
 <cfa83206-4ea7-5949-9db4-99fc495641a4@peersm.com>
 <CAJowKgLh1zS+fFvkVZTLXiqHQ8QMOqxCVooGpby3_o8EHxoihA@mail.gmail.com>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <c9339ca3-d2d1-8006-fef2-c9e9479fb2ce@peersm.com>
Date: Thu, 20 Apr 2023 16:25:30 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAJowKgLh1zS+fFvkVZTLXiqHQ8QMOqxCVooGpby3_o8EHxoihA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------D058FDA76903754188A4C509"
X-Originating-IP: [37.59.142.107]
X-ClientProxiedBy: DAG8EX1.mxp6.local (172.16.2.71) To DAG6EX2.mxp6.local
 (172.16.2.52)
X-Ovh-Tracer-GUID: 5dcf1ee5-3ebe-4ddc-8aae-1d4daa6dad4d
X-Ovh-Tracer-Id: 5429933775854986205
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtvddgjeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhevhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpeethihmvghrihgtucggihhtthgvuceorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqeenucggtffrrghtthgvrhhnpefhteehhfdtjeejffduleeijeegheelueetjefguefgvdehgfektefhjeevudduhfenucffohhmrghinhepuhhtgihoshdrohhrghdpghhithhhuhgsrdgtohhmpdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmnecukfhppeduvdejrddtrddtrddupdefjedrheelrddugedvrddutdejpdelvddrudekgedrudduvddrudehvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtoheplhhishhtshesrggthhhofidutddurdgtohhmpdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdgvrhhikhesqhefvddrtghomhdpoffvtefjohhsthepmhhoheegkedpmh
 houggvpehsmhhtphhouhht
X-Mailman-Approved-At: Fri, 21 Apr 2023 12:13:10 +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: Thu, 20 Apr 2023 14:25:36 -0000

--------------D058FDA76903754188A4C509
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Right, that's why I do not participate any longer, they specify things
for the participants (ie big companies), they disregard whatever
suggestion can be made, they are so slow that when they have specified
something someone else has specified something better, then they throw
away their spec and take what the others have specified

And they are wrong in many design decisions

What I meant is that bitcoin big companies should involve people, who
are not just discussing stupid things all the day like W3C folks but do
the work efficiently


Le 20/04/2023 =C3=A0 15:59, Erik Aronesty a =C3=A9crit :
> i think the w3c is a very good example of a slow train wreck, and we
> should do everything possible to avoid the decisions they made=20
>
> On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Personnally I will never criticize the maintainers, but my comment =
was
>     about the global process, I thought that for something important li=
ke
>     bitcoin there were many devs/maintainers, and as you point out, a P=
R
>     must be done by certified people
>
>     I don't get very well why every company involved in bitcoin do not =
put
>     at least one person in this process (a bit like W3C specs), with
>     different time zone so every time you wake up you don't have to loo=
k
>     at/handle hundreds of requests/comments
>
>     And we can read in the press that bitcoin maintenance is supposed t=
o
>     cost 200M per year, probably false then, but this is worrying to se=
e
>     that devs/maintainers are stepping down one after the other
>
>
>     Le 19/04/2023 =C3=A0 23:33, Andrew Chow via bitcoin-dev a =C3=A9cri=
t :
>     > 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 thi=
nk
>     > 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 sin=
gle
>     > 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 an=
y)
>     > 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, e=
tc.
>     > 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 conce=
rns
>     > 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 <http://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 siz=
e"
>     > 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
>     >
>     > _______________________________________________
>     > bitcoin-dev mailing list
>     > bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>     --=20
>     Sophia-Antipolis, France
>     CV: https://www.peersm.com/CVAV.pdf
>     LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
>     GitHub : https://www.github.com/Ayms
>     A Universal Coin Swap system based on Bitcoin:
>     https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
>     A bitcoin NFT system:
>     https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
>     Move your coins by yourself (browser version):
>     https://peersm.com/wallet
>     Bitcoin transactions made simple:
>     https://github.com/Ayms/bitcoin-transactions
>
>     torrent-live: https://github.com/Ayms/torrent-live
>     node-Tor : https://www.github.com/Ayms/node-Tor
>     Anti-spies and private torrents, dynamic blocklist:
>     http://torrent-live.peersm.com
>     Peersm : http://www.peersm.com
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--=20
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ay=
ms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b=
eed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.p=
eersm.com
Peersm : http://www.peersm.com


--------------D058FDA76903754188A4C509
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Right, that's why I do not participate any longer, they specify
      things for the participants (ie big companies), they disregard
      whatever suggestion can be made, they are so slow that when they
      have specified something someone else has specified something
      better, then they throw away their spec and take what the others
      have specified</p>
    <p>And they are wrong in many design decisions</p>
    <p>What I meant is that bitcoin big companies should involve people,
      who are not just discussing stupid things all the day like W3C
      folks but do the work efficiently<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 20/04/2023 à 15:59, Erik Aronesty a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAJowKgLh1zS+fFvkVZTLXiqHQ8QMOqxCVooGpby3_o8EHxoihA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">i think the w3c is a very good example of a slow
        train wreck, and we should do everything possible to avoid the
        decisions they made </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Thu, Apr 20, 2023 at
          7:09 AM Aymeric Vitte via bitcoin-dev &lt;<a
            moz-do-not-send="true"
            href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Personnally
          I will never criticize the maintainers, but my comment was<br>
          about the global process, I thought that for something
          important like<br>
          bitcoin there were many devs/maintainers, and as you point
          out, a PR<br>
          must be done by certified people<br>
          <br>
          I don't get very well why every company involved in bitcoin do
          not put<br>
          at least one person in this process (a bit like W3C specs),
          with<br>
          different time zone so every time you wake up you don't have
          to look<br>
          at/handle hundreds of requests/comments<br>
          <br>
          And we can read in the press that bitcoin maintenance is
          supposed to<br>
          cost 200M per year, probably false then, but this is worrying
          to see<br>
          that devs/maintainers are stepping down one after the other<br>
          <br>
          <br>
          Le 19/04/2023 à 23:33, Andrew Chow via bitcoin-dev a écrit :<br>
          &gt; Responses in-line.<br>
          &gt; Note that the opinions expressed in this email are my own
          and are not<br>
          &gt; representative of what other maintainers think or
          believe.<br>
          &gt;<br>
          &gt; On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev
          wrote:<br>
          &gt;  &gt;<br>
          &gt;  &gt; Communication has been a challenge on Bitcoin Core
          for what I can<br>
          &gt; tell the entire history of the project. Maintainers merge
          a pull request<br>
          &gt; and provide no commentary on why they’ve merged it.<br>
          &gt;<br>
          &gt; What commentary does there need to be?<br>
          &gt; It's self evident that the maintainer believes the code
          is ready to be<br>
          &gt; merged, and has observed enough ACKs from contributors
          that they are<br>
          &gt; comfortable to do so.<br>
          &gt; You're welcome to ask for clarification, but frankly, I
          don't think<br>
          &gt; having any commentary on merges is going to be helpful or
          more elaborate<br>
          &gt; in any way.<br>
          &gt; Requiring maintainers to have to write explanations for
          every single<br>
          &gt; merge is simply going to increase the burden on them and
          increase the<br>
          &gt; rate of burnout and resignations.<br>
          &gt; We've had too many maintainers step down already.<br>
          &gt; It'll end up being a bunch of boilerplate comments that
          don't say<br>
          &gt; anything meaningful.<br>
          &gt;<br>
          &gt; There are certainly situations where PRs are merged very
          quickly or with<br>
          &gt; otherwise little apparent review.<br>
          &gt; But, as I said, if you ask a maintainer why it was
          merged, the answer<br>
          &gt; will be "I thought it was ready and had enough review".<br>
          &gt; There may be other reasons that made the maintainer think
          it was ready<br>
          &gt; sooner, such as the PR fixes a critical bug or security
          vulnerability,<br>
          &gt; but these reasons aren't going to be stated publicly.<br>
          &gt;<br>
          &gt;  &gt; Maintainers leave a pull request with many ACKs and
          few (if any)<br>
          &gt; NACKs for months and provide no commentary on why they
          haven't merged it.<br>
          &gt;<br>
          &gt; There are currently 320 open PRs and 366 open issues.<br>
          &gt; I wake up every morning to 150+ email notifications
          containing<br>
          &gt; everything that went on overnight, and throughout the
          day, I typically<br>
          &gt; get hundreds more.<br>
          &gt; It's impossible to keep up with everything that goes on
          throughout the repo.<br>
          &gt; ACKs come in sporadically, PRs are updated, reviews are
          posted, etc.<br>
          &gt; Often times PRs are not merged simply because the
          maintainers were not<br>
          &gt; aware that a PR was ready to be merged.<br>
          &gt; Things can simply fall through the cracks.<br>
          &gt;<br>
          &gt; Of course there are other reasons why something might not
          be merged, and<br>
          &gt; these generally fall into the camp of "I don't think it
          has had enough<br>
          &gt; review".<br>
          &gt; It's the maintainer's judgement call to make as to
          whether something has<br>
          &gt; been sufficiently reviewed, and part of the judgement
          call is to<br>
          &gt; consider the quality and competence of the reviewers.<br>
          &gt; If a PR had 100 ACKs but all from random people who have
          never<br>
          &gt; contributed to the project in any capacity, then it's not
          going to be<br>
          &gt; merged because those reviewers would be considered low
          quality.<br>
          &gt; It's not just about the numbers, but also about whether
          the reviewers<br>
          &gt; are people the maintainers think are familiar enough with
          an area and<br>
          &gt; have had a history of thoroughly reviewing PRs.<br>
          &gt; For example, if a reviewer who primarily works on the
          mempool reviewed a<br>
          &gt; PR in the wallet, I would consider their review and ACK
          with less weight<br>
          &gt; because they are unlikely to be familiar with the
          intricacies of the wallet.<br>
          &gt; Obviously that changes over time as they make more
          reviews.<br>
          &gt; For another example, if I see an ACK from a reviewer who
          posts reviews<br>
          &gt; that primarily contain nits on code style and other
          trivialities, I<br>
          &gt; would consider that ACK with less weight.<br>
          &gt;<br>
          &gt; Furthermore, the maintainers are not necessarily the ones
          who block a merge.<br>
          &gt; Part of evaluating if something is ready to be merged is
          to read the<br>
          &gt; comments on a PR.<br>
          &gt; Other frequent contributors may have commented or asked
          questions that<br>
          &gt; haven't been resolved yet.<br>
          &gt; PRs will often not be merged (even if they have ACKs)
          until a maintainer<br>
          &gt; deems that those comments and questions have been
          sufficiently resolved,<br>
          &gt; typically with the commenter stating in some way that
          their concerns<br>
          &gt; were addressed.<br>
          &gt; In these situations, no commentary from maintainers is
          given nor<br>
          &gt; necessary as it should be self evident (by reading the
          comments) that<br>
          &gt; something is controversial.<br>
          &gt; These kinds of comments are not explicit NACKs (so
          someone who is only<br>
          &gt; counting (N)ACKs won't see them), but are blocking
          nonetheless.<br>
          &gt;<br>
          &gt; Lastly, personally I like to review every PR before I
          merge it.<br>
          &gt; This often means that a PR that might otherwise be ready
          to be merged<br>
          &gt; wouldn't be merged by myself as I may not be familiar
          with that part of<br>
          &gt; the codebase.<br>
          &gt; It may also mean that I would require more or specific
          additional people<br>
          &gt; to review a PR before I merge it as I would weight my own
          review less<br>
          &gt; heavily.<br>
          &gt; With several long time maintainers stepping away, this
          may be a factor<br>
          &gt; in PRs taking longer to get merged as the remaining
          maintainers may be<br>
          &gt; less familiar with the parts of the codebase that were
          previously<br>
          &gt; maintained by someone else.<br>
          &gt;<br>
          &gt;  &gt; but a casual observer would have only seen Concept
          ACKs and ACKs with<br>
          &gt; 3 stray NACKs. Many of these casual observers inflated
          the numbers on<br>
          &gt; the <a moz-do-not-send="true" href="http://utxos.org"
            rel="noreferrer" target="_blank">utxos.org</a> site [4]
          signalling support for a soft fork activation<br>
          &gt; attempt.<br>
          &gt;<br>
          &gt; Anyone who thinks that maintainers only look at the
          numbers of (N)ACKs<br>
          &gt; is delusional.<br>
          &gt; As I explained above, there is a whole lot more nuance to
          determining<br>
          &gt; even just the status of the opinions on a PR, nevermind
          the code itself.<br>
          &gt;<br>
          &gt; In this specific example of a soft fork, there is also
          consideration of<br>
          &gt; the opinions outside of the repo itself, such as on this
          mailing list<br>
          &gt; and elsewhere that people discuss soft forks.<br>
          &gt;<br>
          &gt; On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev
          wrote:<br>
          &gt;  &gt; While some simple changes can allow bitcoin to
          surpass ethereum, as<br>
          &gt; usual, like "Allow several OP_RETURN in one tx and no
          limited size"<br>
          &gt; <a moz-do-not-send="true"
            href="https://github.com/bitcoin/bitcoin/issues/27043"
            rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/issues/27043</a><br>
          &gt;  &gt;<br>
          &gt;  &gt; How long it will take remains mysterious<br>
          &gt;<br>
          &gt; No one (maintainers or contributors) is obligated to
          implement anything.<br>
          &gt; A feature request not being implemented is because the
          people who do<br>
          &gt; open PRs are either not interested in implementing the
          feature, or are<br>
          &gt; working on other things that they believe to be higher
          priority.<br>
          &gt; If there is a feature that you want, then you will often
          need to either<br>
          &gt; to it yourself, or pay someone to do it for you.<br>
          &gt;<br>
          &gt; Additionally, a feature may seem like a good idea to you,
          but there are<br>
          &gt; often interactions with other things that may end up
          resulting in it<br>
          &gt; being rejected or need significant revision, especially
          for something<br>
          &gt; which affects transaction relay.<br>
          &gt;<br>
          &gt;<br>
          &gt;<br>
          &gt; Andrew Chow<br>
          &gt;<br>
          &gt; _______________________________________________<br>
          &gt; bitcoin-dev mailing list<br>
          &gt; <a moz-do-not-send="true"
            href="mailto:bitcoin-dev@lists.linuxfoundation.org"
            target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
          &gt; <a moz-do-not-send="true"
            href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
            rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
          <br>
          -- <br>
          Sophia-Antipolis, France<br>
          CV: <a moz-do-not-send="true"
            href="https://www.peersm.com/CVAV.pdf" rel="noreferrer"
            target="_blank">https://www.peersm.com/CVAV.pdf</a><br>
          LinkedIn: <a moz-do-not-send="true"
            href="https://fr.linkedin.com/in/aymeric-vitte-05855b26"
            rel="noreferrer" target="_blank">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a><br>
          GitHub : <a moz-do-not-send="true"
            href="https://www.github.com/Ayms" rel="noreferrer"
            target="_blank">https://www.github.com/Ayms</a><br>
          A Universal Coin Swap system based on Bitcoin: <a
            moz-do-not-send="true"
            href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7"
            rel="noreferrer" target="_blank">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a><br>
          A bitcoin NFT system: <a moz-do-not-send="true"
            href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7"
            rel="noreferrer" target="_blank">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a><br>
          Move your coins by yourself (browser version): <a
            moz-do-not-send="true" href="https://peersm.com/wallet"
            rel="noreferrer" target="_blank">https://peersm.com/wallet</a><br>
          Bitcoin transactions made simple: <a moz-do-not-send="true"
            href="https://github.com/Ayms/bitcoin-transactions"
            rel="noreferrer" target="_blank">https://github.com/Ayms/bitcoin-transactions</a><br>
          <br>
          torrent-live: <a moz-do-not-send="true"
            href="https://github.com/Ayms/torrent-live" rel="noreferrer"
            target="_blank">https://github.com/Ayms/torrent-live</a><br>
          node-Tor : <a moz-do-not-send="true"
            href="https://www.github.com/Ayms/node-Tor" rel="noreferrer"
            target="_blank">https://www.github.com/Ayms/node-Tor</a><br>
          Anti-spies and private torrents, dynamic blocklist: <a
            moz-do-not-send="true" href="http://torrent-live.peersm.com"
            rel="noreferrer" target="_blank">http://torrent-live.peersm.com</a><br>
          Peersm : <a moz-do-not-send="true"
            href="http://www.peersm.com" rel="noreferrer"
            target="_blank">http://www.peersm.com</a><br>
          <br>
          <br>
          _______________________________________________<br>
          bitcoin-dev mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:bitcoin-dev@lists.linuxfoundation.org"
            target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
            rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Sophia-Antipolis, France
CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a>
LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a>
A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a>
A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a>
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre>
  </body>
</html>

--------------D058FDA76903754188A4C509--