add glozow to trusted-keys

glozow commented at 1:25 pm on July 1, 2022: member

For maintaining mempool and policy areas of the codebase, as discussed yesterday’s meeting: https://gnusha.org/bitcoin-core-dev/2022-06-30.log

add glozow to trusted-keys ebe106a754

fanquake added the label Scripts and tools on Jul 1, 2022

darosior approved

darosior commented at 1:52 pm on July 1, 2022: member

Concept ACK

michaelfolkson commented at 3:05 pm on July 1, 2022: contributor

Concept ACK from me too.

Individuals can correct me if I’m not representing their views accurately but from what I could make out from yesterday’s meeting this PR had effective Concept ACKs from: laanwj, fanquake, achow101, cfields_, hebasto, instagibbs, dongcarl, Murch, sipa, b10c, MacroFake, lightlike, michaelfolkson

A mild NACK: jeremyrubin

Sjors commented at 3:05 pm on July 1, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd and congrats!

PGP key looks familiar. In fact, I signed it :-)

achow101 commented at 3:30 pm on July 1, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

I think glozow is a good fit for maintainership and her expertise in mempool and policy makes those areas a good focus for her.

The key fingerprint matches the key I have signed for glozow,

brunoerg approved

brunoerg commented at 4:25 pm on July 1, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

Congrats!

ghost commented at 4:31 pm on July 1, 2022: none

NACK

I had no strong opinion until yesterday and still think she is a good coder and reviewer. However, this pull request gives commit access which I am not sure about:

Reasons:

If this pull request is merged, there will be 7 maintainers and 3 funded by Brink. This was even mentioned by @0xB10C as nit in meeting. Bitcoin has only 1 implementation used by majority of nodes. It would be better if maintainers were from different parts of world and funded by different organizations. Being anon could also be helpful.
Process of adding another maintainer could be improved. One of the suggestion from @ariard was to know if we have other candidates interested for being a maintainer. Others were mainly about scope of a maintainer.
Self merging mempool related pull requests would be different from build, wallet etc. and if this role is just about running a script then it could be done by any of the present maintainers when there are enough ACKs and no technical NACK. There are a few other contributors that are not sure about self merge.
Speculations about full-rbf being default in #25353 by PR author did not look like the right approach. Lot of important pull requests are open that could affect security of different bitcoin projects (positively or negatively) related to mempool. I would prefer status-quo with more reviewers or developers with more experience in Bitcoin Core.
I do not understand why @theuni was trying to stop some people from sharing their thoughts in meeting.
@laanwj also found questions, suggestions etc. from Jeremy Rubin annoying and mentioned that an opinion about PR author being maintainer was changed recently.

I know this NACK would not be considered being a new contributor and this comment by @achow101 however still want to document my thoughts as review for this PR. Also if governments/banks/3 letter agencies would ever try this, I am sure they won’t use new contributors or random accounts based on my experience.

Sjors commented at 5:05 pm on July 1, 2022: member

@1440000bytes full time developers are more likely to get to a skill level where they can be a maintainer. Sponsored developers are more likely able to work full time. Conversely, maintainers are more likely to get sponsorship due to their reputation. Combine that with Pareto’s law, and you’re just going to have a situation where one organisation sponsors a relatively large chunk of maintainers. This happened with Blockstream, then with Chaincode, now with Brink.

If we had a huge surplus of candidate maintainers, then perhaps this sort of stuff could factored in. But we nearly ran out. The maintainers that have been around the longest have all been subjected to legal attacks, which could have forced them to become salary slaves at Google to pay off infinite bills. The lead maintainer has said multiple times he doesn’t want to do this forever.

I’m very happy to see several fresh maintainers step up to this task. It mainly involves ungrateful boring work and personal risk.

If you’re worried about a pattern of malicious merges by maintainers, then rather than blocking new maintainers, a more productive course of action might be to keep a very close eye on what gets merged. It all happens in the open. There’s a signed public record.

theuni commented at 5:16 pm on July 1, 2022: member

5. I do not understand why [@theuni](/bitcoin-bitcoin/contributor/theuni/)  was trying to stop some people from sharing their thoughts in meeting.

@1440000bytes my apologies for my behavior towards you during the meeting. I had no intention of keeping anyone from sharing their thoughts, but it appeared to me at the time as though you were trying to shift the conversation away from a specific nomination for a specific role, to re-framing the conversation to “who else should maybe maintain something?”. This pattern is something that we see very very often to derail an otherwise productive specific conversation, so it set off my alarm.

I should have explained that more calmly rather than assuming the worst and shutting you down. That was uncool and disrespectful.

Again, I’m sorry.

theuni commented at 5:22 pm on July 1, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

jamesob commented at 5:35 pm on July 1, 2022: member

-0, which defaults to NACK from me @glozow is an excellent coder and thinker, and I am hugely supportive of her work, but a few things make me hesitate here. My main concern is that @glozow is a not-impartial participant in the development of mempool design, and she has a number of outstanding proposals and PRs in that area. Presumably she will continue to put forward proposed designs that need to be evaluated by others. I think her role as a maintainer might muddy the waters, and cause others to be more likely to defer to her proposals on the basis of perceived hierarchy.

You can make the argument that other maintainers were in a similar position when inbound, e.g. @achow101 and @hebasto, but things like wallet and GUI and relatively localized to Core, don’t have as wide a design space as mempool, and do not crosscut through the ecosystem in the same way that mempool does. Having a maintainer of the leading implementation who is both maintaining and proposing designs seems like a possible conflict.

I think an ideal maintainer is someone who is well-grounded enough to have good familiarity with the domain, but who has enough distance to be able to impartially adjudicate the suitability and technical appetite for a PR’s merge.

There are also specific instances that make me uncertain, albeit to a minor degree, about her judgement as a maintainer. The recent exchange in #25461 does not inspire confidence from my end. Many of Gloria’s mempool proposals I heartily support (conceptually at the very least - I’m behind on my review) but proposals that e.g. involve doing replacement policy on the basis of caching block templates (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020124.html) strike me as fairly opinionated and controversial. Of course I don’t begrudge people suggesting things that are speculative - it’s just tough to dissociate that activity from a place in the (soft) power structure.

And then there are ancillary concerns that are a little harder to articulate:

If maintainership is really just “janitorial,” as the refrain commonly goes, and progress in this repo is bottlenecked by review, why do we need more maintainers? Why not just more “ready for merge?” pings?
This is hard to express without coming off as impolite or ad hominem, but we have a pretty large plurality of young maintainers who don’t really have a lot of experience in other projects. Furthermore, this plurality seems pretty tightly linked in terms of funding, personal life, etc. to the point where I’ve heard concern expressed from other contributors that there may be a “virtuous circle” of mutual ACKs among maintainers. I’m not trying to criticize or alienate, but I think the potential for weirdness is growing.

Anyway, all this to say that I’m a huge fan of Gloria’s work and I really hope it continues. A lot of Bitcoin’s future is contingent on fixing the mempool, and she’s been a big part of that over the last two years. I just have various reservations that amount to a -0, which - when considering something like maintainership - defaults to a NACK.

If we’re going to have another maintainer, I’d like to see someone who is a little further removed, more experienced in the repo, and somewhat more disjoint from the funding/social graph.

But I also think we need to back up a little and answer: if maintainers really are just “janitors,” why do we need another maintainer? Do we need to revisit the role of maintainers? Should they be expected to take a more active role in setting goals for regions of the system - if so, that’s okay (and I think might even solve some problems!) but we should make that explicit instead of just repeating this maintainers-are-just-janitors line while kind of implicitly expecting something else.

brunoerg commented at 6:23 pm on July 1, 2022: member

If this pull request is merged, there will be 7 maintainers and 3 funded by Brink. This was even mentioned by @0xB10C as nit in meeting. Bitcoin has only 1 implementation used by majority of nodes. It would be better if maintainers were from different parts of world and funded by different organizations. Being anon could also be helpful. @1440000bytes; It’s a good point, but I think organizations give developers enough power to work autonomously, so people in the same organization don’t mean they work together or make decisions together. Even people from different orgs they may be funded by the same source (e.g. same exchange donating for different orgs). Anyway, I agree with the concern, it would be great if we had more sources of funding.

Sjors commented at 7:51 pm on July 1, 2022: member

I don’t think “janitorial” implies that it’s very little work. Just that it shouldn’t depend too much on personal opinion.

dergoegge commented at 9:12 pm on July 1, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

achow101 commented at 5:31 am on July 2, 2022: member

Self merging mempool related pull requests would be different from build, wallet etc. and if this role is just about running a script then it could be done by any of the present maintainers when there are enough ACKs and no technical NACK. There are a few other contributors that are not sure about self merge.

I think concerns about self merging are overblown. Self merges are not that common, and I think it is widely understood that self merges are not a good look. Just because someone is a maintainer does not mean that the code they write is going to automatically be merged, particularly by themselves.

I think an ideal maintainer is someone who is well-grounded enough to have good familiarity with the domain, but who has enough distance to be able to impartially adjudicate the suitability and technical appetite for a PR’s merge.

I don’t see how that would be possible if that person were not directly implementing code in those areas prior to maintainership. To build up the expertise required to have the familiarity with the domain would require working on it directly, and so inherently run into your issue of conflict of interest.

If maintainership is really just “janitorial,” as the refrain commonly goes, and progress in this repo is bottlenecked by review, why do we need more maintainers? Why not just more “ready for merge?” pings?

Obviously part of a maintainer’s job is to evalulate whether a PR is ready for merging. Having subject matter expertise makes it easier to make that judgement call. If maintainers are blindly trusting the “ready for merge” calls of particular individuals because they are considered experts, then those people are pseudo-maintainers and should be given merge rights to reduce friction. Otherwise “ready for merge” pings still require assessing whether a PR is ready for merging.

As assessing whether a PR is ready for merge involves both looking at the code and readying through review comments and (N)ACKs, a subject matter expert is far better equipped to make that judgement call with confidence. They will be more familiar with the code itself and could leave a review. They will be more familiar with those who are working in those areas and be able to know how much to weight those people’s reviews. This changes what is looked for when assessing whether a PR is ready to be merged.

As an example, if I were to look at an area of code that I am not familiar with, I may not be able to leave my own ACK on it because I am not confident in my own review. I may wait for several more ACKs than would otherwise be necessary for the PR to be merged, e.g. waiting for 5 people to ACK rather than 3. This ends up extending the amount of time a “ready for merge” PR sits unmerged, and of course brings us back around to the problem of not having enough reviewers. If there were a maintainer who was an expert in that area of code, then they may be able to supply their own review. They may be able to determine that the PR is ready to be merged at 3 ACKs and so merge the PR at that point instead of waiting for additional review. In this way, maintainers who are experts in certain areas allow us to get things merged faster.

michaelfolkson commented at 11:23 am on July 2, 2022: contributor

I should have explained that more calmly rather than assuming the worst and shutting you down. That was uncool and disrespectful.

Again, I’m sorry. @theuni: I was rather perplexed why you were apologizing so I reread the conversation log of the meeting and there is absolutely nothing to apologize for. There is a weekly hour long Core dev meeting so when someone (in this case a maintainer) brings a topic (glozow for rbf / mempool / validation maintainer) people shouldn’t have to be asked multiple times to stick to the topic (as you were forced to and as the host of the meeting was forced to multiple times). There have been a number of months since the last maintainer was added (achow101) and plenty of opportunity to discuss changing the process for adding maintainers (whether they should have to commit to one-to-one meetings with certain contributors or not etc). All the maintainers are ACKing this and effectively saying they would like another maintainer added to cover mempool/policy.

If there are particular concerns with glozow taking on this role (@jamesob raises a couple in his post in a thoughtful way which is absolutely fine, this criticism isn’t directed towards him) or individual(s) think there is a better candidate than glozow for this role then that is on topic and should be discussed. But discussing who should be the next maintainer(s) after glozow or throwing half baked suggestions around about what glozow should have to do and how far she should have to jump before she becomes a maintainer is totally inappropriate.

fanquake approved

fanquake commented at 8:36 am on July 4, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

hebasto approved

hebasto commented at 10:54 am on July 4, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd, confirming my approval given at the IRC meeting.

MarcoFalke commented at 1:13 pm on July 4, 2022: member

Concept ACK.

Some replies:

I think concerns about self merging are overblown. Self merges are not that common, and I think it is widely understood that self merges are not a good look. Just because someone is a maintainer does not mean that the code they write is going to automatically be merged, particularly by themselves. (From #25524 (comment) , and a few comments on IRC)

I agree with your other points in your comment, but I disagree about self merges. First, I think that self merges are common. I estimate that about half of my changes are merged by myself, the same estimate should hold for fanquake and you. (I used git log --merges --since=$date --author="$name1" --grep="$name2" --oneline | wc -l to estimate very roughly). In fact, in the absence of several active maintainers per file/module, I fail to see how self merges could be rare.

Also, I don’t think self merges are not a good look, simply because they are self merges. Before a change is merged, it should be reviewed. If a change is merged without sufficient review or with outstanding concerns, it should be proposed for a revert (regardless of whether it was a self merge or not). I fail to see how a process that discourages (or even forbids) self-merges is helpful in any way. If anything, it would increase the distraction and burden on other maintainers to keep their constant attention on modules they may not primarily be interested in. (Hypothetically, taking this to the extreme, a requirement for maintainers to perform a dance for each other to avoid a self merge could create a “virtuous circle”, which was actually used as rationale for a NACK above.)

“funding” (From various comments)

Surely funding open source software development is in an early stage and there are many ways it could be improved. However, I’d be concerned if the constantly changing funding landscape was used as a criteria to evaluate the technical proficiency of contributors in the scope of this project. Needless to say that the same goes for the country of residence (or anything not related to this software project) of contributors. If this was used as a criteria, are we going to remove maintainers/contributors as soon as their source of funding changes to a source that already funds a maintainer/contributor?

“questions about the role of maintainers” (From various comments)

Generally, I find it questionable that potentially unclear documentation about the role of maintainers are used as a reason to NACK this proposal. The role of maintainers is explained in https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md . I see that the explanation could be updated, based on the discussions on IRC and GitHub. However, it seems absurd to reject a perfectly capable and motivated maintainer candidate based on this.

Maintainers (just like every other contributor) of this project are evaluated based on the quality of their technical contributions. Suggestions to extend evaluation criteria to also cover unrelated topics (such as funding, country of residence, age, personal life, as well as experience in other projects or work-related settings), seems not only a process burden, but would likely backfire and achieve the opposite of what the stated goal was. Surely there are imperfections (of process documentation and otherwise), but I highly doubt that refusing glozow as a maintainer is going to fix them.

0xB10C commented at 10:51 am on July 5, 2022: member

Concept ACK (I don’t have a PGP pubkey from glozow I could check against, so ACKing a particular commit doesn’t make sense).

sipa commented at 2:30 pm on July 5, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd, though relying on others to verify the PGP key.

mzumsande commented at 2:35 pm on July 5, 2022: member

Concept ACK (don’t have a key to check against).

Maintainers (just like every other contributor) of this project are evaluated based on the quality of their technical contributions.

For me, social aspects (e.g. how people act in conflicts) are more important in maintainers, and the quality of their review is a more important factor than the quality of their own PRs. So for me, it’s an overlapping but not identical set of evaluation criteria - but I agree that real-life factors shouldn’t play a role.

laanwj commented at 3:53 pm on July 5, 2022: member

ACK ebe106a754d2da567702e60185142d9e381bf1cd

I’ve checked that the key 6B002C6EA3F91B1B0DF0C9BC8F617F1200A6D25C matches other sources where @glozow ’s key can be found. However, no commits in the repository seem to be signed with it, nor does she have an entry in contrib/builder-keys/keys.txt.

If we’re going to have another maintainer, I’d like to see someone who is a little further removed, more experienced in the repo, and somewhat more disjoint from the funding/social graph.

I think we should be happy she wants to do this. It’s not easy to find people who are both qualified and enthusiastic to be maintainer. And for good reason it’s a lot of responsibility and definitely not always fun.

Many of Gloria’s mempool proposals I heartily support (conceptually at the very least - I’m behind on my review) but proposals that e.g. involve doing replacement policy on the basis of caching block templates (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020124.html) strike me as fairly opinionated and controversial.

Yes, maintainership is not an excuse to push controversial ideas. This should not result in less thorough discussion and evaluation of ideas. But I trust Gloria in that regard.

luke-jr commented at 0:23 am on July 6, 2022: member

Meta-Concept NACK to adding a maintainer while other contributors are NACKing: Would like to see the reasoned NACKs disappear first. However, no objections of my own.

If you’re worried about a pattern of malicious merges by maintainers, then rather than blocking new maintainers, a more productive course of action might be to keep a very close eye on what gets merged. It all happens in the open. There’s a signed public record.

Unfortunately, such things get ignored, and those merges haven’t been reverted.

MarcoFalke commented at 7:48 am on July 6, 2022: member

If you’re worried about a pattern of malicious merges by maintainers, then rather than blocking new maintainers, a more productive course of action might be to keep a very close eye on what gets merged. It all happens in the open. There’s a signed public record.

Unfortunately, such things get ignored, and those merges haven’t been reverted.

I am confused why you keep bringing this up. To revert a patch, a pull request has to be submitted for review. This shouldn’t be significantly harder than typing git revert .... Given that other reverts went through, however not a single person has opened one about the “malicious merges” you are referring to, I have a hard time following how this means “things get ignored”. In any case, it is off-topic to discuss case examples in this thread, so I recommend to continue this discussion elsewhere.

josibake commented at 2:03 pm on July 6, 2022: member

ACK https://github.com/bitcoin/bitcoin/pull/25524/commits/ebe106a754d2da567702e60185142d9e381bf1cd (i have not personally signed this key, but verified it matches other places glozow has posted her key)

as a quick reminder, we are ACK/NACK’ing whether or not glozow has the technical prowess, knowledge, and experience to evaluate open patches and merge them if they have sufficient review and consensus from other contributors, specifically patches that relate to mempool and policy. given her experience with the mempool and policy areas of the codebase, i believe she is qualified for this. id also add that her experience with the PR review club demonstrates her practice and ability as an expert reviewer, which makes her a good fit for a maintainer.

regarding the NACKs, it seems they are less about glozow and more about larger, difficult-to-address concerns:

having multiple maintainers funded by the same entity could be bad
the process of adding maintainers could be better
concerns about age, social circles, etc of maintainers

i don’t want to seem dismissive of these concerns (some of them are things i also spend a lot of time thinking about), but this is not a productive place to raise them. if these are legitimate problems, they have existed before this proposal and blocking glozow from being a maintainer will not make them better. id kindly ask those who have more general concerns to instead focus on the specific proposal and if they do have a NACK, to express concrete, addressable points.

id also like to point out that this is not a one-way door: maintainers can be revoked if there is evidence of abuse. lastly, id caution against putting maintainers on too high a pedestal. as contributors, we should all be testing and closely evaluating what is merged and ultimately decide for ourselves what code we want to run on our node and encouraging others to do the same. this is in part why bitcoin has a 6-month release cycle; this gives ample time to discuss and revert changes before the next release, even if they have been merged to master.

jamesob commented at 2:23 pm on July 6, 2022: member

Meta-Concept NACK to adding a maintainer while other contributors are NACKing: Would like to see the reasoned NACKs disappear first. However, no objections of my own.

Clearly there is sufficient “rough consensus” to add @glozow as a maintainer. My own reservations were fairly marginal, and they should not hold up this merge.

ghost commented at 4:08 pm on July 6, 2022: none

The maintainers that have been around the longest have all been subjected to legal attacks, which could have forced them to become salary slaves at Google to pay off infinite bills. The lead maintainer has said multiple times he doesn’t want to do this forever.

This was one of the reasons I mentioned different countries in my comment. It is difficult to do such attack with people in different countries. I have read some of these posts:

https://laanwj.github.io/2021/01/21/decentralize.html https://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html

If you’re worried about a pattern of malicious merges by maintainers, then rather than blocking new maintainers, a more productive course of action might be to keep a very close eye on what gets merged. It all happens in the open. There’s a signed public record.

Yes, maintainership is not an excuse to push controversial ideas. This should not result in less thorough discussion and evaluation of ideas. But I trust Gloria in that regard.

It is easier to merge controversial or less reviewed pull requests once you are a maintainer. There are a few examples.

I should have explained that more calmly rather than assuming the worst and shutting you down. That was uncool and disrespectful. Again, I’m sorry. @theuni No problem :)

Meta-Concept NACK to adding a maintainer while other contributors are NACKing: Would like to see the reasoned NACKs disappear first. However, no objections of my own.

This discussion could have been avoided if there was a better process. I am still not comfortable as PR author being a maintainer however would be okay if this is merged as most of the contributors ACKed it.

A rough diagram of how the improved process would look like:

Example of ‘Call for maintainers’: https://github.com/graphql-python/graphene/issues/1312

luke-jr commented at 7:06 pm on July 6, 2022: member

This was one of the reasons I mentioned different countries in my comment. It is difficult to do such attack with people in different countries.

In practice, it hasn’t been. Despite none of the defendants/victims residing in the UK (some never having even set foot there), the plaintiff/attacker still managed to abuse the UK courts as an attack on all at once.

ariard commented at 0:45 am on July 7, 2022: member

Concept ACK

Minding the layered scaling of Bitcoin, the mempool is on good track to become one of the most safety-critical component of the ecosystem. Apart of package relay, it’s likely we’ll have to land other big works (e.g Eltoo support) and also think about cleaning up the current quagmire. So in my opinion, it deserves well its own maintainer and a lot of care and attention.

I think Gloria is not only one of the most qualified contributor we have for the job but also the most motivated one. Or at least, I don’t sense the other developers qualified for mempool maintenance are interested for the role. I can sense the concern about the 2 years of experience only. Though I would like to note that those 2 years of contributions have been really prolific and that any year of experience in Bitcoin Core likely counts for five in a more traditional software engineering career. I can understand that for some contributors the “perfect” candidate would be someone with decades of experience in open-source system engineering, a PhD in side-channel differential analysis, tens of briefing tenures at BlackHat, posts on bitcointalk.org pre-dating 2011 and why not a Turing (joke, we don’t care about someone’s degrees or age or other social proofs in bitcoin protocol dev, or do we ?).

I believe of course it’s better if maintainers have more a “blue” profile than “red” (as those terms are used in cybersecurity jargon). People who have a lot of care for following the rules and ensuring all the checks have been done over a predilection for breaking stuff. Especially in Bitcoin, I think maintenance requires a lot of thoroughness, cautiouness and patience. I would say Gloria have demonstrated those qualities in the past and as such qualifies well for the role. Of course, for any experienced contributor you can find a counter-example of lack of patience stucking in some old page of the repository. Everyone has bad day, no one is perfect.

I would say it’s better to think maintenance as scoped, or at least to know who merges what well-defined. Not only between maintainers (to avoid merges not meeting the usual review bar) but also in the eyes of the contributors to know whom should be the default interlocutor in case of questions on such or such subsystem. As already echoed, I also believe it would be great to have any consensus change to have a review/merge process of its own (where maybe the merge could be counter-signed by a N-of-M of the maintainers).

I don’t have that much concerns about the self-merging practice itself. As the codebase is growing in complexity in face of a near-constant review bandwidth, they might become a necessity to keep the project afloat. However, when the code area under scrutinity is high-impact, high-risk like the mempool or p2p, I think we might want a formal engineering process. Like proposing the changes on the ML for wide community feedback, PoCing out the changes, ensuring objections had time to be raised, advanced testing to be conducted, etc. In that regards, self-merging is only a minor step of the process and what matters more is clear communication by the project champion. Of course, project process would always be up to bikeshedding and everyone has its own definition of the correct amount. There is also the fact even if we have best-practices on the paper, it’s FOSS so it doesn’t mean we’ll have the engineering time and energy to enforce them. With process, too much, we’re bleeding people, too low, we’re bleeding people’s money.

I can hear some contributors who would like to do a wider risks assessment of a maintainer candidate. After all, there was a past maintainer swearing to have met the ghost of Satoshi. Though honestly, if we do so I believe no one would meet the bar as again human perfection doesn’t exist. If there is an issue with the performance of a janitorial task, better to talk about it when it happens.

I don’t feel worried with a maintainers concentration at Brink. Thinking about the reality of FOSS, maintenance is a high-time consuming, low-margin activity so it’s more likely people occupying that type of roles ends up attracted by a non-profit with long-term time horizons. The Brink folks are always open to feedbacks on how to make things more transparent and accountable for the wider community. I believe anyone can feel free to talk with them on developers centralization and other “Bitcoin Foundation bis-repetita” concerns at conferences around a beer. From my experience they’re mindful about it.

Lastly, I think it’s accurate that being part of an organization might make it easier to move forward your stuff. However I think it just reflects the reality of current Bitcoin protocol development where to an always increasing amount of complexity it’s better to know how to team up to solve the challenges. I’m not sure about the argument we should make contributor X less prolific to make things more fair towards contributor Y…

Anyways, thanks to Gloria for offering the maintenance commitment.

JeremyRubin commented at 0:57 am on July 7, 2022: contributor

concept ACK on adding @glozow (will see if I have a verified key…)

i made some thoughts on maintainership here as a more general topic. #25560

I think Gloria is a good candidate as she has been working in the mempool & transaction relay policy space dedicatedly for the last year or two, and has made solid contributions. I also appreciate that she has a decent list of interest areas she might spend time on as a maintainer https://gist.github.com/glozow/5b8cfa27945371921dfe4d99b17e0424 . I’d love to see that list fleshed out a bit more, but it gives me a solid concept on where her efforts will be focused.

I still have the concern around self merges being particularly problematic given a dearth of other subject matter experts in the areas that @glozow is scoped, but I trust @glozow to not abuse her privileges in that regard.

willcl-ark commented at 9:54 am on July 7, 2022: member

ACK adding Gloria as maintainer with focus on mempool & policy. She has good knowledge of this area of the codebase and based on her character, her past actions and her contributions to the space in general, I determine that she would be a good and impartial maintainer for Bitcoin Core.

I had this key already in my keyring, but have not verified it in real life :)

Xekyo commented at 2:26 pm on July 7, 2022: member

Edit: Someone that tested my signature found that it naturally failed since GitHub squashed the commit fingerprint which was full length in my message. The following should work better. You can find my key at: https://murch.one/pubkey.asc

 0-----BEGIN PGP SIGNED MESSAGE-----
 1Hash: SHA256
 2
 3ACK ebe106a754d2da567702e60185142d9e381bf1cd.
 4
 5I have verified Gloria's fingerprint 6B002C6EA3F91B1B0DF0C9BC8F617F1200A6D25C in person and signed her key. I delivered the two UID-certificates separately and encrypted, which means she has demonstrated control of the associated email addresses and possession of the key to me.
 6
 7Don't trust, verify. ;)
 8
 9New York, 2022-07-07
10Murch
11-----BEGIN PGP SIGNATURE-----
12
13iQIzBAEBCAAdFiEENfStpiPrn+OjvH72e6A1yluQFxMFAmLG7HEACgkQe6A1yluQ
14FxP7jA//b9RI3I7QgdBEWhGA7vFqTEq2lM3cdogWv5/NU7baxaR/4mQw1qVt76d2
15Qwpo3aoUdDBBu/1ogIparqPYd1e/11W/BNO47lhYYR9ZOxqJatAQOg4GuzghOUx+
167zS73X3A1gQx/ULSmzdK53i8ntxFb2TMqGTutFnIa485Lt2ZVlei4qRPbyogyJqq
173S44cyBZCoWZ5Hzwn1CCAa2skJ5wCLc5nVUvD7tjM/osKbCMURz6fGBOXZ6GuXtQ
18qzag+8XIgfwNoPsUM8DHt0C2FW2rCDWvTaTlDZ1m6nH2P5QQfBgX4Rgkjz+xDojO
19w0IBcZPk1hUZKLbCGgKebOCMfLvKqc3Eekt9oobwRoG2tfq9GyF5VAB11ysF22XQ
20Seq7R3NjicRHtEsy6UWj3Oh3ZqfhXT+sZ8OjuVf8PaSbxyGREi4zxHPQb59dhlTG
21eUGV5o9cU8IWYw3d65cWQ8rsuzh755SjUFJ7Cy1yWCPUpssECfZI5TqOptFLohsY
22LegjLVrcEhCANq6xnLxNzbtgKtSMOaCiEn+CZnlD4w4a/fPqtwRGulmCIKPnhy+e
23N5OYXMncSRsJNW06X6K64Ozkidccgzx6naRwpkSteTUxarCRZ4N/FRjGvFuX39Sh
24SjFNdDbY531oYwWA2PwUpaVTEDjfTqcqnEFTjsl1uBhvdXZo990=
25=4Kp9
26-----END PGP SIGNATURE-----

MarcoFalke commented at 3:49 pm on July 7, 2022: member

The merge script spat out an error:

Merge message contains an @!

Thus, I’ve edited one of the comments: #25524 (comment)

MarcoFalke merged this on Jul 7, 2022

MarcoFalke closed this on Jul 7, 2022

glozow deleted the branch on Jul 8, 2022

fanquake deleted a comment on Jul 9, 2022

MarcoFalke locked this on Jul 10, 2022

add glozow to trusted-keys #25524