Skip to content

Instantly share code, notes, and snippets.

@michaelfolkson
Last active May 8, 2023 22:53
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save michaelfolkson/81df14508ed3ad3232da133e154d6873 to your computer and use it in GitHub Desktop.
Thoughts on the addition of Core maintainers

Thoughts on the addition of Core maintainers

Historically I'm not aware of any long term Core contributor putting themselves forward as a potential Core maintainer and being rejected/blocked. We recently saw that with Vasil Dimov where two maintainers (fanquake, glozow) blocked him from becoming a maintainer for 5 months with Vasil eventually closing the related pull request.

When it is a contributor who has clearly demonstrated value and expertise opening pull requests and reviewing pull requests over a number of years (in Vasil's case in a part of the codebase that existing maintainers aren't familiar with covering Tor, I2P, alternative networks etc) there really should be a solid rationale for blocking that long term contributor from becoming a maintainer. I was always under the impression that the maintainer role was essentially janitorial. Of course occasionally there are disagreements between long term contributors and these views have to be weighed up when assessing whether to merge or not merge a particular pull request. But two maintainers blocking a long term contributor from becoming a maintainer is not janitorial. That is an opinionated stance that held for 5 months until another maintainer (Andrew Chow) reversed his initial ACK and NACKed the pull request shortly before Vasil closed it.

The only valid reasons I can think of for blocking such a long term contributor from becoming a maintainer are related to temperament and/or trust. There is nothing I am aware of that suggests Vasil is lacking in either. (This is assuming an upper limit on the number of desired maintainers hasn't been reached. Clearly not every long term contributor needs or should be a maintainer.)

Andrew Chow has now proposed ryanofsky as a new maintainer. Again a long term contributor who has clearly demonstrated value and expertise opening pull requests and reviewing pull requests over a number of years. Surely it is fair to apply the same rationale that was belatedly given by Andrew (5 months after Vasil's PR was opened) to justify blocking Vasil from becoming a maintainer to ryanofsky? Or is requesting and scrutinizing these rationales "rude" and "aggressive" as I have been accused of being and anyone who isn't a maintainer should just accept the decisions made by current maintainers? It feels like to me that the current maintainers have a very different approach to previous maintainers (Wladimir etc) who were happy to discuss their merge decisions on IRC. Andrew is the most responsive but fanquake, glozow seem to think they can make whatever decisions they like and don't have to explain them or justify them to anyone publicly. Assuming this is true this is concerning with regards to merge decisions generally (including potentially contentious ones) on top of this particular issue of the addition of new maintainers.

@harding
Copy link

harding commented May 8, 2023

Addressing the two lines in the above that end with question marks, as the rest seems to be information or your opinion (which, of course, you're entitled to):

Surely it is fair to apply the same rationale that was belatedly given by Andrew (5 months after Vasil's PR was opened) to justify blocking Vasil from becoming a maintainer to ryanofsky?

Sure, that seems fair, although I don't think a previous criteria should be expected to be exhaustive or binding---situations and opinions change.

is requesting and scrutinizing these rationales "rude" and "aggressive" as I have been accused of being [...]?

Following some of your links, I believe I found the source of you being called rude and aggressive:

< michaelfolkson> Ok so comment on the PR sipa and _aj_ that another maintainer isn't needed and NACK it
[...]
< MacroFake> michaelfolkson: sipa already said that on the pull
< michaelfolkson> MacroFake: He didn't NACK it
[...]
< MacroFake> michaelfolkson: I think it is rude to request others to NACK a pull
[...]
< michaelfolkson> You saying fanquake and glozow are CIA _aj_?
[...]
< achow101> frankly, I think opinions aren't being shared because of potential backlash from aggressive users such as yourself and bytes1440000

I think rude and aggressive are accurate descriptions of your behavior there.

anyone who isn't a maintainer should just accept the decisions made by current maintainers?

Nobody has to accept the decisions made by current maintainers. Everyone receiving a copy of the Bitcoin Core source code has the ability to modify it and share those modified versions. That's what open source means. It doesn't mean that the people who helped create that software have do anything for you.

@michaelfolkson
Copy link
Author

I think rude and aggressive are accurate descriptions of your behavior there.

What exactly? Requesting people NACK it if they feel strongly? Responding to AJ posting a link to the CIA sabotage field manual?

11:20 < _aj_> this entire topic seems much more like it's following https://www.openculture.com/2022/01/read-the-cias-simple-sabotage-field-manual.html rather than trying to solve actual problems to me

@michaelfolkson
Copy link
Author

michaelfolkson commented May 8, 2023

That's what open source means. It doesn't mean that the people who helped create that software have do anything for you.

Your view is the maintainers can make whatever decisions they like with regards to the addition or blocking of new maintainers or the merging of pull requests generally and they don't need to explain those decisions to anyone publicly? On an open source project with the dominance that Bitcoin Core has and with many considering it the reference client? Just want to clarify what your view is here. It really is a shocking view. You effectively want to hand over permanent control of the Bitcoin consensus rules to a small number of maintainers who can do whatever they want.

@michaelfolkson
Copy link
Author

You know what, don't bother responding. I don't have the energy any more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment