diff options
| author | Erik Aronesty <erik@q32.com> | 2023-04-20 09:59:07 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-04-20 13:59:21 +0000 |
| commit | 10e82333991bf3282dc9e3a7a012b1d904e172e0 (patch) | |
| tree | bc826ffeb3b24f38065f769b8cf475336f2e66e1 | |
| parent | 1eb575b140fa2f4b28184facef9ff5b914657950 (diff) | |
| download | pi-bitcoindev-10e82333991bf3282dc9e3a7a012b1d904e172e0.tar.gz pi-bitcoindev-10e82333991bf3282dc9e3a7a012b1d904e172e0.zip | |
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
| -rw-r--r-- | f8/583c69f46caf0caacf08c337bf5d4e35914e07 | 576 |
1 files changed, 576 insertions, 0 deletions
diff --git a/f8/583c69f46caf0caacf08c337bf5d4e35914e07 b/f8/583c69f46caf0caacf08c337bf5d4e35914e07 new file mode 100644 index 000000000..4ac188e7c --- /dev/null +++ b/f8/583c69f46caf0caacf08c337bf5d4e35914e07 @@ -0,0 +1,576 @@ +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= + <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.linuxfoundation.org</a>> 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'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 =C3=A0 23:33, Andrew Chow via bitcoin-dev a =C3=A9crit :<br> +> Responses in-line.<br> +> Note that the opinions expressed in this email are my own and are not<= +br> +> representative of what other maintainers think or believe.<br> +><br> +> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:<br> +>=C2=A0 ><br> +>=C2=A0 > Communication has been a challenge on Bitcoin Core for what= + I can<br> +> tell the entire history of the project. Maintainers merge a pull reque= +st<br> +> and provide no commentary on why they=E2=80=99ve merged it.<br> +><br> +> What commentary does there need to be?<br> +> It's self evident that the maintainer believes the code is ready t= +o be<br> +> merged, and has observed enough ACKs from contributors that they are<b= +r> +> comfortable to do so.<br> +> You're welcome to ask for clarification, but frankly, I don't = +think<br> +> having any commentary on merges is going to be helpful or more elabora= +te<br> +> in any way.<br> +> Requiring maintainers to have to write explanations for every single<b= +r> +> merge is simply going to increase the burden on them and increase the<= +br> +> rate of burnout and resignations.<br> +> We've had too many maintainers step down already.<br> +> It'll end up being a bunch of boilerplate comments that don't = +say<br> +> anything meaningful.<br> +><br> +> There are certainly situations where PRs are merged very quickly or wi= +th<br> +> otherwise little apparent review.<br> +> But, as I said, if you ask a maintainer why it was merged, the answer<= +br> +> will be "I thought it was ready and had enough review".<br> +> There may be other reasons that made the maintainer think it was ready= +<br> +> sooner, such as the PR fixes a critical bug or security vulnerability,= +<br> +> but these reasons aren't going to be stated publicly.<br> +><br> +>=C2=A0 > Maintainers leave a pull request with many ACKs and few (if= + any)<br> +> NACKs for months and provide no commentary on why they haven't mer= +ged it.<br> +><br> +> There are currently 320 open PRs and 366 open issues.<br> +> I wake up every morning to 150+ email notifications containing<br> +> everything that went on overnight, and throughout the day, I typically= +<br> +> get hundreds more.<br> +> It's impossible to keep up with everything that goes on throughout= + the repo.<br> +> ACKs come in sporadically, PRs are updated, reviews are posted, etc.<b= +r> +> Often times PRs are not merged simply because the maintainers were not= +<br> +> aware that a PR was ready to be merged.<br> +> Things can simply fall through the cracks.<br> +><br> +> Of course there are other reasons why something might not be merged, a= +nd<br> +> these generally fall into the camp of "I don't think it has h= +ad enough<br> +> review".<br> +> It's the maintainer's judgement call to make as to whether som= +ething has<br> +> been sufficiently reviewed, and part of the judgement call is to<br> +> consider the quality and competence of the reviewers.<br> +> If a PR had 100 ACKs but all from random people who have never<br> +> contributed to the project in any capacity, then it's not going to= + be<br> +> merged because those reviewers would be considered low quality.<br> +> It's not just about the numbers, but also about whether the review= +ers<br> +> are people the maintainers think are familiar enough with an area and<= +br> +> have had a history of thoroughly reviewing PRs.<br> +> For example, if a reviewer who primarily works on the mempool reviewed= + a<br> +> PR in the wallet, I would consider their review and ACK with less weig= +ht<br> +> because they are unlikely to be familiar with the intricacies of the w= +allet.<br> +> Obviously that changes over time as they make more reviews.<br> +> For another example, if I see an ACK from a reviewer who posts reviews= +<br> +> that primarily contain nits on code style and other trivialities, I<br= +> +> would consider that ACK with less weight.<br> +><br> +> Furthermore, the maintainers are not necessarily the ones who block a = +merge.<br> +> Part of evaluating if something is ready to be merged is to read the<b= +r> +> comments on a PR.<br> +> Other frequent contributors may have commented or asked questions that= +<br> +> haven't been resolved yet.<br> +> PRs will often not be merged (even if they have ACKs) until a maintain= +er<br> +> deems that those comments and questions have been sufficiently resolve= +d,<br> +> typically with the commenter stating in some way that their concerns<b= +r> +> were addressed.<br> +> In these situations, no commentary from maintainers is given nor<br> +> necessary as it should be self evident (by reading the comments) that<= +br> +> something is controversial.<br> +> These kinds of comments are not explicit NACKs (so someone who is only= +<br> +> counting (N)ACKs won't see them), but are blocking nonetheless.<br= +> +><br> +> Lastly, personally I like to review every PR before I merge it.<br> +> This often means that a PR that might otherwise be ready to be merged<= +br> +> wouldn't be merged by myself as I may not be familiar with that pa= +rt of<br> +> the codebase.<br> +> It may also mean that I would require more or specific additional peop= +le<br> +> to review a PR before I merge it as I would weight my own review less<= +br> +> heavily.<br> +> With several long time maintainers stepping away, this may be a factor= +<br> +> in PRs taking longer to get merged as the remaining maintainers may be= +<br> +> less familiar with the parts of the codebase that were previously<br> +> maintained by someone else.<br> +><br> +>=C2=A0 > but a casual observer would have only seen Concept ACKs and= + ACKs with<br> +> 3 stray NACKs. Many of these casual observers inflated the numbers on<= +br> +> 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> +> attempt.<br> +><br> +> Anyone who thinks that maintainers only look at the numbers of (N)ACKs= +<br> +> is delusional.<br> +> As I explained above, there is a whole lot more nuance to determining<= +br> +> even just the status of the opinions on a PR, nevermind the code itsel= +f.<br> +><br> +> In this specific example of a soft fork, there is also consideration o= +f<br> +> the opinions outside of the repo itself, such as on this mailing list<= +br> +> and elsewhere that people discuss soft forks.<br> +><br> +> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:<br> +>=C2=A0 > While some simple changes can allow bitcoin to surpass ethe= +reum, as<br> +> usual, like "Allow several OP_RETURN in one tx and no limited siz= +e"<br> +> <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> +>=C2=A0 ><br> +>=C2=A0 > How long it will take remains mysterious<br> +><br> +> No one (maintainers or contributors) is obligated to implement anythin= +g.<br> +> A feature request not being implemented is because the people who do<b= +r> +> open PRs are either not interested in implementing the feature, or are= +<br> +> working on other things that they believe to be higher priority.<br> +> If there is a feature that you want, then you will often need to eithe= +r<br> +> to it yourself, or pay someone to do it for you.<br> +><br> +> Additionally, a feature may seem like a good idea to you, but there ar= +e<br> +> often interactions with other things that may end up resulting in it<b= +r> +> being rejected or need significant revision, especially for something<= +br> +> which affects transaction relay.<br> +><br> +><br> +><br> +> Andrew Chow<br> +><br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">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= +/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-- + |