path: root/f8/583c69f46caf0caacf08c337bf5d4e35914e07

Return-Path: <earonesty@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CAA57C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 13:59:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id AF1C0841DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 13:59:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org AF1C0841DB
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com
 header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=x/hJbUAq
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ZT7Qur1EIeoT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 13:59:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org BB12C8411D
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com
 [IPv6:2607:f8b0:4864:20::1133])
 by smtp1.osuosl.org (Postfix) with ESMTPS id BB12C8411D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 13:59:19 +0000 (UTC)
Received: by mail-yw1-x1133.google.com with SMTP id
 00721157ae682-54fdeddabd7so1715917b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Apr 2023 06:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20221208.gappssmtp.com; s=20221208; t=1681999158; x=1684591158;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=26rnAsB1Y+oMRcGZHGkwEhq79sWcv3Jwi3zUzIE61V8=;
 b=x/hJbUAqlIncBsYAzzkdlIkom7RmKjqrG6EOqZzjtmXvMiSlRH7oyvNQ0r+SHrOKXX
 JEFllSVrciCC/nvdBRgi3ou8ZGA1uNwCD3V4u00m4zqVbFAFJjQyiplTwEEbtpm29Mfm
 RnYG9xS7BFtPYJBOIsseR7TxUiqhrfKJPTuZd6nNIebZZOZAh78vaHBI380H2qkdUYA5
 b9nOCK8qW5hvfGkWIkaANzmP3XEd11gq6G/KUuNHmqWsEEVy0tI/SrhsAsBTPsljGEn2
 02iH4NYuBTO+4Fq80K3mX4TTgNUkSpXAKUVw3ro0J6iTBbkwuEAGZyeCc9nwY8wOifjO
 U3fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1681999158; x=1684591158;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=26rnAsB1Y+oMRcGZHGkwEhq79sWcv3Jwi3zUzIE61V8=;
 b=fYuJFu/JHr2c2qTMlY+s6Xt661I451Ugx1TUlo4MmSvCLXhcq6bo4SaAIIO8qlq7kR
 nbBEcKgW5axDF5GR8dk8yZCd4bvxMEDUdU4hqM1sOciOdO4Jv0JvsKuAlqHQqhRklnu/
 KXA6hKR6Sc0eN6+vR3kmOW7/OHHxantd5o/JSAGxT7QfEDdlX7ePsuTVNqeqfcOinXk2
 fTpu8VqO1rmE/ZGgXOy8Vn1fqY0VPw/FxjNBEeduqRuASywA0VFaqKrAlfb/IGwsQW3U
 vknOn8KJ1Agj809o6ttcVg8x/in3fJpXWQxF6GOG3eOKDztBHEb48mmpo/WaOouekfAx
 XZgw==
X-Gm-Message-State: AAQBX9cPgNrFZiTQ+UtqivuSNU3MoNr3mVXgZcgsH8PRcTepON5pQ3I3
 He+2PLZcoP0QnkbE/y8NLVXoz/34tygm/z3IAm0Bqso=
X-Google-Smtp-Source: AKy350Ykc1f8FGJ8dXlJyDXZ3C0KFrXo13dS/bd3bmKjABmUjW4F9ukv6y8f+9288QCKLRwIftCtZOh/4gYw6ZIMRh8=
X-Received: by 2002:a81:1710:0:b0:53c:70c5:45d2 with SMTP id
 16-20020a811710000000b0053c70c545d2mr808399ywx.0.1681999158455; Thu, 20 Apr
 2023 06:59:18 -0700 (PDT)
MIME-Version: 1.0
References: <uuq_VbxJp50_-m4ufKpEhJOknhZ0pvK8ioDabCkxtDjBYauO3gLKrj2O2tjS6YIFOnJLyaZg6-LENzom1DyQQ3TyMLIIaGz5IRrzrKB8gRs=@protonmail.com>
 <feef7f88-b46d-7355-1716-122afc6359ee@achow101.com>
 <cfa83206-4ea7-5949-9db4-99fc495641a4@peersm.com>
In-Reply-To: <cfa83206-4ea7-5949-9db4-99fc495641a4@peersm.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 20 Apr 2023 09:59:07 -0400
Message-ID: <CAJowKgLh1zS+fFvkVZTLXiqHQ8QMOqxCVooGpby3_o8EHxoihA@mail.gmail.com>
To: Aymeric Vitte <aymeric@peersm.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005a330305f9c4f2c0"
X-Mailman-Approved-At: Thu, 20 Apr 2023 14:04:20 +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 13:59:21 -0000

--0000000000005a330305f9c4f2c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev <
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 like
> bitcoin there were many devs/maintainers, and as you point out, a PR
> 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 look
> at/handle hundreds of requests/comments
>
> And we can read in the press that bitcoin maintenance is supposed to
> cost 200M per year, probably false then, but this is worrying to see
> 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=A9crit :
> > 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 reques=
t
> > 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 elaborat=
e
> > 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 wit=
h
> > 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 i=
t.
> >
> > 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, an=
d
> > 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 ha=
s
> > 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 weigh=
t
> > 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 maintaine=
r
> > 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 peopl=
e
> > 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 wit=
h
> > 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
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000005a330305f9c4f2c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">i think the w3c is a very good example of a slow train wre=
ck, and we should do everything possible to avoid the decisions they made=
=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"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&#39;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&#39;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 =C3=A0 23:33, Andrew Chow via bitcoin-dev a =C3=A9crit :<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;=C2=A0 &gt;<br>
&gt;=C2=A0 &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 reque=
st<br>
&gt; and provide no commentary on why they=E2=80=99ve merged it.<br>
&gt;<br>
&gt; What commentary does there need to be?<br>
&gt; It&#39;s self evident that the maintainer believes the code is ready t=
o be<br>
&gt; merged, and has observed enough ACKs from contributors that they are<b=
r>
&gt; comfortable to do so.<br>
&gt; You&#39;re welcome to ask for clarification, but frankly, I don&#39;t =
think<br>
&gt; having any commentary on merges is going to be helpful or more elabora=
te<br>
&gt; in any way.<br>
&gt; Requiring maintainers to have to write explanations for every single<b=
r>
&gt; merge is simply going to increase the burden on them and increase the<=
br>
&gt; rate of burnout and resignations.<br>
&gt; We&#39;ve had too many maintainers step down already.<br>
&gt; It&#39;ll end up being a bunch of boilerplate comments that don&#39;t =
say<br>
&gt; anything meaningful.<br>
&gt;<br>
&gt; There are certainly situations where PRs are merged very quickly or wi=
th<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 &quot;I thought it was ready and had enough review&quot;.<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&#39;t going to be stated publicly.<br>
&gt;<br>
&gt;=C2=A0 &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&#39;t mer=
ged 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&#39;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.<b=
r>
&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, a=
nd<br>
&gt; these generally fall into the camp of &quot;I don&#39;t think it has h=
ad enough<br>
&gt; review&quot;.<br>
&gt; It&#39;s the maintainer&#39;s judgement call to make as to whether som=
ething 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&#39;s not going to=
 be<br>
&gt; merged because those reviewers would be considered low quality.<br>
&gt; It&#39;s not just about the numbers, but also about whether the review=
ers<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 weig=
ht<br>
&gt; because they are unlikely to be familiar with the intricacies of the w=
allet.<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<b=
r>
&gt; comments on a PR.<br>
&gt; Other frequent contributors may have commented or asked questions that=
<br>
&gt; haven&#39;t been resolved yet.<br>
&gt; PRs will often not be merged (even if they have ACKs) until a maintain=
er<br>
&gt; deems that those comments and questions have been sufficiently resolve=
d,<br>
&gt; typically with the commenter stating in some way that their concerns<b=
r>
&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&#39;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&#39;t be merged by myself as I may not be familiar with that pa=
rt of<br>
&gt; the codebase.<br>
&gt; It may also mean that I would require more or specific additional peop=
le<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;=C2=A0 &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 href=3D"http://utxos.org" rel=3D"noreferrer" target=3D"_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 itsel=
f.<br>
&gt;<br>
&gt; In this specific example of a soft fork, there is also consideration o=
f<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;=C2=A0 &gt; While some simple changes can allow bitcoin to surpass ethe=
reum, as<br>
&gt; usual, like &quot;Allow several OP_RETURN in one tx and no limited siz=
e&quot;<br>
&gt; <a href=3D"https://github.com/bitcoin/bitcoin/issues/27043" rel=3D"nor=
eferrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/issues/27043<=
/a><br>
&gt;=C2=A0 &gt;<br>
&gt;=C2=A0 &gt; How long it will take remains mysterious<br>
&gt;<br>
&gt; No one (maintainers or contributors) is obligated to implement anythin=
g.<br>
&gt; A feature request not being implemented is because the people who do<b=
r>
&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 eithe=
r<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 ar=
e<br>
&gt; often interactions with other things that may end up resulting in it<b=
r>
&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 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
-- <br>
Sophia-Antipolis, France<br>
CV: <a href=3D"https://www.peersm.com/CVAV.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://www.peersm.com/CVAV.pdf</a><br>
LinkedIn: <a href=3D"https://fr.linkedin.com/in/aymeric-vitte-05855b26" rel=
=3D"noreferrer" target=3D"_blank">https://fr.linkedin.com/in/aymeric-vitte-=
05855b26</a><br>
GitHub : <a href=3D"https://www.github.com/Ayms" rel=3D"noreferrer" target=
=3D"_blank">https://www.github.com/Ayms</a><br>
A Universal Coin Swap system based on Bitcoin: <a href=3D"https://gist.gith=
ub.com/Ayms/029125db2583e1cf9c3209769eb2cdd7" rel=3D"noreferrer" target=3D"=
_blank">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a><b=
r>
A bitcoin NFT system: <a href=3D"https://gist.github.com/Ayms/01dbfebf21996=
5054b4a3beed1bfeba7" rel=3D"noreferrer" target=3D"_blank">https://gist.gith=
ub.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a><br>
Move your coins by yourself (browser version): <a href=3D"https://peersm.co=
m/wallet" rel=3D"noreferrer" target=3D"_blank">https://peersm.com/wallet</a=
><br>
Bitcoin transactions made simple: <a href=3D"https://github.com/Ayms/bitcoi=
n-transactions" rel=3D"noreferrer" target=3D"_blank">https://github.com/Aym=
s/bitcoin-transactions</a><br>
<br>
torrent-live: <a href=3D"https://github.com/Ayms/torrent-live" rel=3D"noref=
errer" target=3D"_blank">https://github.com/Ayms/torrent-live</a><br>
node-Tor : <a href=3D"https://www.github.com/Ayms/node-Tor" rel=3D"noreferr=
er" target=3D"_blank">https://www.github.com/Ayms/node-Tor</a><br>
Anti-spies and private torrents, dynamic blocklist: <a href=3D"http://torre=
nt-live.peersm.com" rel=3D"noreferrer" target=3D"_blank">http://torrent-liv=
e.peersm.com</a><br>
Peersm : <a href=3D"http://www.peersm.com" rel=3D"noreferrer" target=3D"_bl=
ank">http://www.peersm.com</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005a330305f9c4f2c0--