Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Erik Aronesty <erik@q32.com>]

[-- Attachment #1: Type: text/plain, Size: 9201 bytes --]

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 AM 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 à 23:33, Andrew Chow via bitcoin-dev a écrit :
> > 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’ve merged it.
> >
> > What commentary does there need to be?
> > It's self evident that the maintainer believes the code is ready to be
> > merged, and has observed enough ACKs from contributors that they are
> > comfortable to do so.
> > You're welcome to ask for clarification, but frankly, I don't think
> > having any commentary on merges is going to be helpful or more elaborate
> > in any way.
> > Requiring maintainers to have to write explanations for every single
> > merge is simply going to increase the burden on them and increase the
> > rate of burnout and resignations.
> > We've had too many maintainers step down already.
> > It'll end up being a bunch of boilerplate comments that don't say
> > anything meaningful.
> >
> > There are certainly situations where PRs are merged very quickly or with
> > otherwise little apparent review.
> > But, as I said, if you ask a maintainer why it was merged, the answer
> > will be "I thought it was ready and had enough review".
> > There may be other reasons that made the maintainer think it was ready
> > sooner, such as the PR fixes a critical bug or security vulnerability,
> > but these reasons aren't going to be stated publicly.
> >
> >  > Maintainers leave a pull request with many ACKs and few (if any)
> > NACKs for months and provide no commentary on why they haven't merged it.
> >
> > There are currently 320 open PRs and 366 open issues.
> > I wake up every morning to 150+ email notifications containing
> > everything that went on overnight, and throughout the day, I typically
> > get hundreds more.
> > It's impossible to keep up with everything that goes on throughout the
> repo.
> > ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> > Often times PRs are not merged simply because the maintainers were not
> > aware that a PR was ready to be merged.
> > Things can simply fall through the cracks.
> >
> > Of course there are other reasons why something might not be merged, and
> > these generally fall into the camp of "I don't think it has had enough
> > review".
> > It's the maintainer's judgement call to make as to whether something has
> > been sufficiently reviewed, and part of the judgement call is to
> > consider the quality and competence of the reviewers.
> > If a PR had 100 ACKs but all from random people who have never
> > contributed to the project in any capacity, then it's not going to be
> > merged because those reviewers would be considered low quality.
> > It's not just about the numbers, but also about whether the reviewers
> > are people the maintainers think are familiar enough with an area and
> > have had a history of thoroughly reviewing PRs.
> > For example, if a reviewer who primarily works on the mempool reviewed a
> > PR in the wallet, I would consider their review and ACK with less weight
> > because they are unlikely to be familiar with the intricacies of the
> wallet.
> > Obviously that changes over time as they make more reviews.
> > For another example, if I see an ACK from a reviewer who posts reviews
> > that primarily contain nits on code style and other trivialities, I
> > would consider that ACK with less weight.
> >
> > Furthermore, the maintainers are not necessarily the ones who block a
> merge.
> > Part of evaluating if something is ready to be merged is to read the
> > comments on a PR.
> > Other frequent contributors may have commented or asked questions that
> > haven't been resolved yet.
> > PRs will often not be merged (even if they have ACKs) until a maintainer
> > deems that those comments and questions have been sufficiently resolved,
> > typically with the commenter stating in some way that their concerns
> > were addressed.
> > In these situations, no commentary from maintainers is given nor
> > necessary as it should be self evident (by reading the comments) that
> > something is controversial.
> > These kinds of comments are not explicit NACKs (so someone who is only
> > counting (N)ACKs won't see them), but are blocking nonetheless.
> >
> > Lastly, personally I like to review every PR before I merge it.
> > This often means that a PR that might otherwise be ready to be merged
> > wouldn't be merged by myself as I may not be familiar with that part of
> > the codebase.
> > It may also mean that I would require more or specific additional people
> > to review a PR before I merge it as I would weight my own review less
> > heavily.
> > With several long time maintainers stepping away, this may be a factor
> > in PRs taking longer to get merged as the remaining maintainers may be
> > less familiar with the parts of the codebase that were previously
> > maintained by someone else.
> >
> >  > but a casual observer would have only seen Concept ACKs and ACKs with
> > 3 stray NACKs. Many of these casual observers inflated the numbers on
> > the utxos.org site [4] signalling support for a soft fork activation
> > attempt.
> >
> > Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> > is delusional.
> > As I explained above, there is a whole lot more nuance to determining
> > even just the status of the opinions on a PR, nevermind the code itself.
> >
> > In this specific example of a soft fork, there is also consideration of
> > the opinions outside of the repo itself, such as on this mailing list
> > and elsewhere that people discuss soft forks.
> >
> > On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
> >  > While some simple changes can allow bitcoin to surpass ethereum, as
> > usual, like "Allow several OP_RETURN in one tx and no limited size"
> > https://github.com/bitcoin/bitcoin/issues/27043
> >  >
> >  > How long it will take remains mysterious
> >
> > No one (maintainers or contributors) is obligated to implement anything.
> > A feature request not being implemented is because the people who do
> > open PRs are either not interested in implementing the feature, or are
> > working on other things that they believe to be higher priority.
> > If there is a feature that you want, then you will often need to either
> > to it yourself, or pay someone to do it for you.
> >
> > Additionally, a feature may seem like a good idea to you, but there are
> > often interactions with other things that may end up resulting in it
> > being rejected or need significant revision, especially for something
> > which affects transaction relay.
> >
> >
> >
> > Andrew Chow
> >
> > _______________________________________________
> > 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
>

[-- Attachment #2: Type: text/html, Size: 11829 bytes --]