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"
Subject: Re: [bitcoin-dev] Bitcoin Core maintainers and communication on
	merge decisions
Precedence: list

--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--