There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the
Core dev IRC meeting [0] yesterday it received multiple ACKs.
The decision process for adding a new maintainer was according to the IRC
meeting that the maintainers decided privately there was a need for a
maintainer “who understood our interfaces and modularization efforts well” and
that ryanofsky was a “good fit for that”. I don’t know whether this was decided
in a private IRC channel or was decided at the recent in person Core Dev
meeting. Regardless, many have had no input into the discussion on what kind of
maintainer the project needs going forward and it seems the maintainers do not
want to discuss that aspect of the decision.
I posted a couple of questions in advance [1] of the meeting (I was unable to
attend) that remained unanswered during the meeting. Essentially my concern is
going forward current maintainers will decide which proposed new maintainers to
add and which to block. If you aren’t anointed by the current maintainers you
won’t get added as a maintainer and a half baked rationale will be provided to
justify that decision. Longer term this will determine the pull requests that
will ultimately get merged and which don't get merged because maintainers merge
pull requests.
One of the justifications for blocking Vasil Dimov as a new maintainer despite
many initial ACKs from maintainers (including Andrew Chow) and long term
contributors was according to Andrew [2]:
“Maintainers inherently need to look at the things that everyone else has
already looked at, if only to give it a final once over before merging (but
hopefully, an actual review, not just looking it over).”
I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do
this any more than Vasil does. This is not a criticism of ryanofsky, just as I
wouldn’t use it as a criticism for Vasil. It would get pretty annoying if
everyone who wasn’t a maintainer posted an ACK once many long term contributors
had already ACKed to display supposed “desired maintainer traits”. Especially
if you are essentially just ACKing that others have done the work to review the
PR and you just want to get your ACK on it to increase your ACK count without
doing a fraction of what previous reviewers have done.
“I also want to mention that the people who have become maintainers in the past
have had this kind of maintainer attitude towards review prior to becoming a
maintainer”
Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a
criticism from me at least) does this mean this was a reason to block Vasil but
not a reason to block ryanofsky? That seems inconsistent to me. When you’re
anointed you don’t need to meet requirements but when you’re blocked these
requirements will be used to block your addition as a new maintainer?
For what it is worth from a personal perspective I don’t see any reason for
blocking ryanofsky as a maintainer especially if there is broad agreement
amongst maintainers and long term contributors that we need a new maintainer
who understands interfaces and modularization on the project. For that framing
ryanofsky perfectly meets those requirements. But once again the (public)
discussion element on the addition of maintainers is essentially a façade, a
framing for what the new maintainer needs to be has been decided in advance (in
private) and an anointed individual who just so happens to align with that
convenient framing will get added as a new maintainer.
On a more positive note there does seem to be more energy and momentum for
collaboration and open communication on the project since I discussed
communication in a previous post [3]. Hopefully this will continue. It doesn’t
address my concerns on maintainers and ultimately merge decisions but it
definitely seems to me to be a step in a positive direction for the project.
[0]: https://gnusha.org/bitcoin-core-dev/2023-05-04.log
[1]: https://gnusha.org/bitcoin-core-dev/2023-05-01.log
[2]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1382334059
[3]:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021565.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Tuesday, April 18th, 2023 at 13:40, Michael Folkson
<michaelfolk...@protonmail.com> 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. 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. I can only speculate on why and it probably depends
> on the individual maintainer. Sometimes it will be poor communication skills,
> sometimes it will be a desire to avoid accountability, sometimes it will be
> fear of unreasonable and spiteful legal action if they mistakenly merge a
> pull request that ends up containing a bug. But search through the pull
> requests on Bitcoin Core and you will rarely see a rationale for a merge
> decision. The difference between say previous maintainers like Wladimir and
> some of the current maintainers is that previous maintainers were extremely
> responsive on IRC. If you disagreed with a merge decision or thought it had
> been merged prematurely they would be happy to discuss it on IRC. In present
> times at least a subset of the current maintainers are not responsive on IRC
> and will refuse to discuss a merge decision. One farcical recent example [0]
> was the pull request to add Vasil Dimov as a maintainer where despite many
> ACKs from other maintainers and other long term contributors two maintainers
> (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It
> took almost 5 months for Gloria to comment on the pull request despite many
> requests from me on the PR and on IRC. I even requested that they attend the
> weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>
> A pull request to add a maintainer isn’t a normal pull request. Generally
> pull requests contain a lot more lines of code than a single line adding a
> trusted key. Not merging a pull request for a long period of time can be
> extremely frustrating for a pull request author especially when maintainers
> and long term contributors don’t comment on the pull request and the pull
> request is stuck in “rebase hell”. Clearly it is the lesser evil when
> compared to merging a harmful or bug ridden pull request but poor
> non-existent communication is not the only way to prevent this. Indeed it
> creates as many problems as it solves.
>
> Another farcical recent(ish) example was the CTV pull request [1] that
> ultimately led to a contentious soft fork activation attempt that was called
> off at the last minute. If you look at the comments on the pull request there
> were 3 individuals (including myself) who NACKed the pull request and I think
> it is fair to say that none of us would be considered long term contributors
> to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing
> to pursue a soft fork activation attempt when it was clear it was contentious
> [3] but if you look at the pull request comments it certainly isn’t clear it
> was. Maintainers and long term contributors (if they commented at all) were
> gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to
> merge. A long term observer of the Core repo would have known that it wasn’t
> ready to merge or ready to attempt to activate (especially given it was a
> consensus change) 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.
>
> I set out originally to write about the controls and processes around merges
> on the default signet (bitcoin-inquisition [5]) but it quickly became obvious
> to me that if communication around Core merges/non-merges is this weak you
> can hardly expect it to be any better on bitcoin-inquisition/default signet
> where there is no real monetary value at stake. I will probably write about
> bitcoin-inquisition/default signet in a future email as I do think the
> perception that it is “the one and only” staging ground for consensus changes
> is dangerous [6] if the maintainer(s) on that project have the same
> inclinations as a subset of the Core maintainers.
>
> As I stated at the beginning there is an element to this which is not
> individual(s) specific and an adverse reaction to outright malicious actors
> external to any of these projects. I do not think any of the current
> maintainers on Core or bitcoin-inquisition are outright malicious even if a
> subset of them consistently frustrate me with their lack of transparency and
> accountability. But this issue isn't going away and I'm sure we'll hear more
> on this from others in the coming months. To me it is a straight choice of
> taking transparency and accountability much more seriously or failing that
> investing more heavily (time and resources) in consensus compatible forks of
> Core and treating Core like it is a proprietary "open source" project where
> merge decisions are not explained or justified in the open.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
