Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CAA57C002A for ; 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 ; 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 ; 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 ; Thu, 20 Apr 2023 13:59:19 +0000 (UTC) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-54fdeddabd7so1715917b3.1 for ; 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: In-Reply-To: From: Erik Aronesty Date: Thu, 20 Apr 2023 09:59:07 -0400 Message-ID: To: Aymeric Vitte , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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

On Thu, Apr 20, 2023 at 7:09=E2=80=AFAM Aymeric Vitte via bitcoin-dev= <bitcoin-dev@l= ists.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<= br> 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<= br> > representative of what other maintainers think or believe.
>
> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
>=C2=A0 >
>=C2=A0 > Communication has been a challenge on Bitcoin Core for what= I can
> tell the entire history of the project. Maintainers merge a pull reque= st
> 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 t= o 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 elabora= te
> 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<= br> > 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 wi= th
> otherwise little apparent review.
> 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".
> 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.
>
>=C2=A0 > Maintainers leave a pull request with many ACKs and few (if= any)
> NACKs for months and provide no commentary on why they haven't mer= ged 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, a= nd
> these generally fall into the camp of "I don't think it has h= ad enough
> review".
> It's the maintainer's judgement call to make as to whether som= ething 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 review= ers
> are people the maintainers think are familiar enough with an area and<= br> > 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 weig= ht
> because they are unlikely to be familiar with the intricacies of the w= allet.
> 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 maintain= er
> deems that those comments and questions have been sufficiently resolve= d,
> 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<= br> > 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<= br> > wouldn't be merged by myself as I may not be familiar with that pa= rt of
> the codebase.
> It may also mean that I would require more or specific additional peop= le
> to review a PR before I merge it as I would weight my own review less<= br> > 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.
>
>=C2=A0 > 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<= br> > 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<= br> > even just the status of the opinions on a PR, nevermind the code itsel= f.
>
> In this specific example of a soft fork, there is also consideration o= f
> the opinions outside of the repo itself, such as on this mailing list<= br> > and elsewhere that people discuss soft forks.
>
> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
>=C2=A0 > While some simple changes can allow bitcoin to surpass ethe= reum, as
> usual, like "Allow several OP_RETURN in one tx and no limited siz= e"
> https://github.com/bitcoin/bitcoin/issues/27043<= /a>
>=C2=A0 >
>=C2=A0 > How long it will take remains mysterious
>
> No one (maintainers or contributors) is obligated to implement anythin= g.
> 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 eithe= r
> to it yourself, or pay someone to do it for you.
>
> Additionally, a feature may seem like a good idea to you, but there ar= e
> often interactions with other things that may end up resulting in it > being rejected or need significant revision, especially for something<= br> > 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.gith= ub.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Aym= s/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-liv= e.peersm.com
Peersm : http://www.peersm.com


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000005a330305f9c4f2c0--