19:00:31 <laanwj> #startmeeting 
19:00:31 <core-meetingbot> Meeting started Thu Jun 30 19:00:31 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:31 <core-meetingbot> Available commands: action commands idea info link nick
19:00:49 <hebasto> hi
19:00:50 <jarolrod> hi
19:00:50 <sdaftuar> hi
19:00:54 <cfields_> hi
19:00:58 <sipa> hi
19:01:00 <fanquake> hi
19:01:01 <instagibbs> hi
19:01:02 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo
19:01:02 <glozow> hi
19:01:04 <laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:07 <lightlike> hi
19:01:14 <MacroFake> hi
19:01:19 <ariard> hi
19:01:21 <laanwj> welcome to the weekly general bitcoin-core-dev meeting
19:01:36 <kvaciral> hi
19:01:43 <michaelfolkson> hi
19:01:48 <laanwj> there has been one topic proposed in advance: glozow for rbf / mempool / validation maintainer (fanquake)
19:02:01 <laanwj> you can propose topics at any time during the week with #proposedmeetingtopic
19:02:06 <laanwj> any last minute topics?
19:02:45 <achow101> hi
19:02:59 <b10c> hi
19:03:49 <kanzure> hi
19:04:32 <laanwj> #topic High priority for review
19:04:32 <core-meetingbot> topic: High priority for review
19:05:12 <laanwj> there are 7 blockers, 2 chasing concept ACK in https://github.com/orgs/bitcoin/projects/1
19:05:14 <MacroFake> #24697 for me pls (It makes removing adjusted time a little bit easier, but it is not strictly required)
19:05:16 <gribble> https://github.com/bitcoin/bitcoin/issues/24697 | refactor address relay time by MarcoFalke · Pull Request #24697 · bitcoin/bitcoin · GitHub
19:05:26 <laanwj> (the URL moved, as we migrated the project to the new github projects)
19:06:18 <dongcarl> #25487 for me please!
19:06:20 <gribble> https://github.com/bitcoin/bitcoin/issues/25487 | [kernel 3b/n] Make `{Dump,Load}Mempool` `CTxMemPool` methods, decouple from `ArgsManager` by dongcarl · Pull Request #25487 · bitcoin/bitcoin · GitHub
19:06:51 <laanwj> MacroFake: added
19:07:01 <MacroFake> Maybe #21702 can be removed for needing rebase?
19:07:03 <gribble> https://github.com/bitcoin/bitcoin/issues/21702 | Implement BIP-119 Validation (CheckTemplateVerify) by JeremyRubin · Pull Request #21702 · bitcoin/bitcoin · GitHub
19:07:26 <laanwj> dongcarl: also added
19:07:26 <dongcarl> Ping jeremyrubin
19:07:31 <MacroFake> Same for #22693 ?
19:07:33 <gribble> https://github.com/bitcoin/bitcoin/issues/22693 | RPC/Wallet: Add "use_txids" to output of getaddressinfo by luke-jr · Pull Request #22693 · bitcoin/bitcoin · GitHub
19:07:43 <fanquake> Can I have https://github.com/bitcoin/bitcoin/pull/25484. Few changes building on top of that
19:08:03 <achow101> #24699 for me
19:08:06 <gribble> https://github.com/bitcoin/bitcoin/issues/24699 | wallet: Improve AvailableCoins performance by reducing duplicated operations by achow101 · Pull Request #24699 · bitcoin/bitcoin · GitHub
19:08:47 <luke-jr> I can prioritise a rebase of that
19:09:02 <laanwj> achow101: added
19:09:25 <laanwj> MacroFake: depends on how long it has needed rebase imo
19:10:18 <MacroFake> Yeah, one week seems fine, but if something is sitting for several weeks, I am not sure what reviewers can do
19:10:29 <Murch> hi
19:10:50 <laanwj> agree
19:11:44 <laanwj> looks like it has needed rebase since may 6
19:11:51 <laanwj> so yes removing it for now
19:13:11 <laanwj> okay, anything else to add/remove, or that is in the list and almost ready for merge?
19:15:46 <luke-jr> squashes a cricket
19:16:07 <laanwj> (btw, if you have a project board, and want to migrate it to the new github projects beta, let me know, this is possible now)
19:16:18 <laanwj> #topic glozow for rbf / mempool / validation maintainer
19:16:19 <core-meetingbot> topic: glozow for rbf / mempool / validation maintainer
19:16:28 <fanquake> Cool
19:16:38 <laanwj> ack
19:16:39 <fanquake> Per the topic, I'm proposing we make Gloria (https://github.com/glozow) a maintainer; over ~ rbf / mempool / policy
19:16:47 <fanquake> She has been actively working on Bitcoin Core for > 2 years. Predominately in the mempool & validation code.
19:16:57 <fanquake> Her current project is package rbf/relay, and I know she has a number of thoughts in regards to improving the surrounding code.
19:17:08 <fanquake> More recently she has also been reviewing / helping improve in /wallet/, which I'm sure achow appreciates
19:17:14 <fanquake> I think she is a great candidate for being a maintainer
19:17:25 <achow101> ack
19:17:31 <cfields_> +1
19:17:37 <hebasto> ack
19:17:40 <sipa> The obvious question, glozow: are you interested in helping out with maintaining?
19:17:47 <instagibbs> lol
19:17:57 <MacroFake> sipa: sssh
19:17:57 <instagibbs> (ack)
19:17:59 <luke-jr> who said she has a choice? /s
19:17:59 <cfields_> err.. assuming ^^ :)
19:18:16 <glozow> thanks fanquake, I appreciate the recognition. Yes I'd like to help out in any way I can.
19:18:18 <dongcarl> ack if she wants it
19:18:21 <michaelfolkson> Who is currently merging mempool/policy PRs? Marco?
19:18:28 <Murch> ack
19:18:34 <sipa> ack, in that case
19:18:40 <b10c> ack
19:18:53 <MacroFake> sgtm
19:19:08 <laanwj> awesome!
19:19:16 <b10c> nit: brink would then fund 3 maintainers. not that this is a problem, i just want to mention it.
19:19:27 <jeremyrubin> i am mild nack on it -- i think that Gloria is suitable and qualified, but i think that maintainership might hinder more than help her progress
19:19:44 <jeremyrubin> since it seems it would largely be her with merge resposnibility over her own work
19:20:17 <dongcarl> what does glozow think?
19:20:19 <instagibbs> this seems like a larger question(which is valid) on self-merges
19:20:30 <achow101> jeremyrubin: the same was with the wallet for me
19:20:31 <MacroFake> jeremyrubin: Somewhat it is a requirement to have worked extensively on a piece of code before you can maintain it
19:20:33 <cfields_> jeremyrubin: doesn't seem far off from fanquake's role/work to me.
19:20:38 <cfields_> right, and achow101.
19:20:40 <luke-jr> jeremyrubin: I don't know that's a problem. Maintainers tend to work in the area they merge in
19:20:41 <achow101> at least it will help with getting other people's work in too
19:21:02 <luke-jr> the process of merging still requires third party review
19:21:12 <sipa> I think this was brought up with achow101's maintainership as well, and I think the counterpoints are similar: it's better than having their own work merged at all, and that is something other maintainers can still do.
19:21:14 <sipa> *not merged at all
19:21:51 <glozow> Spending time in this area of the codebase has led me to understand that we have plenty of non-package-relay limitations to address, and reviewing mempool and policy-related things is often the best use of my time. So I had planned to do more of that anyway. Not that this means dropping package relay, but there are lots of non-package relay things to look after. And if people are not comfortable with me merging my own code, then I won't do
19:21:51 <glozow> that.
19:21:56 <laanwj> luke-jr: sipa: exactly
19:22:26 <ariard> i think it's always okay to say to a maintainer we have found the merge too fast or not matching the historical level of reviews for a critical area of the codebase
19:22:46 <lightlike> ack
19:23:05 <luke-jr> ariard: counterpoint, last time that was ignored and the PR not reverted as it ought to have been
19:23:34 <ariard> luke-jr: as usual, one contributor viewpoint might not express the project consensus
19:24:15 <luke-jr> it means there is no consensus; and I certainly was not alone
19:24:16 <jeremyrubin> well to be clear this is very different role than maybe fanquake or achow
19:24:29 <jeremyrubin> since this is -- as desrcribed here -- "validation maintainer"
19:24:30 <bytes1440000> b10c: its a good point and maintainers funded by different orgs is always better for a project like bitcoin core
19:24:38 <sipa> luke-jr: ignoring specific cases, i agree that nobody should feel restricted from commenting on too-fast-merges.
19:24:39 <luke-jr> in any case, it's not related to the topic of glozow's role IMO
19:24:41 <ariard> though to express wider thought on the mempool maintership, imo it's one area of the codebase expected to grow in complexity in the coming years with upper layers requirements
19:25:03 <ariard> like we'll likely have a bunch of other beasts like package relay to land in the coming decade for all the covenants/eltoo stuff
19:25:27 <bytes1440000> i am not sure if bitcoin core needs another person with commit access with already 6 but always felt it needs more reviewers looking at open pull requests
19:25:33 <jeremyrubin> a wallet maintainer affects mostly those who choose to user the software, it's not clear what the scope is of a validation maintainter to me
19:25:56 <laanwj> mempool maintainer is much clearer
19:26:07 <bytes1440000> ariard: you could also be a mempool maintainer?
19:26:28 <cfields_> bytes1440000: that's not the discussion now.
19:26:34 <MacroFake> I think "validation" is meant in the context of mempool validation? (ATMP is in validation.cpp)
19:26:38 <laanwj> i'm also not really sure what 'validation maintainer' would be
19:26:41 <jeremyrubin> maybe we could do a better job of drafting an actual "Job Description" for what glozow is being appiinted as?
19:26:55 <ariard> bytes1440000: no, i don't intend to be maintainer, i don't have the profile for and when it has been proposed to me for LDK, i did refuse
19:26:57 <sipa> ariard: I'm not sure that's all that related to specific consensus changes, but sure... i do expect significant complexity and the need for people keeping a good overview over it, regarding tx relay
19:26:59 <fanquake> I did clarify to mempool / rbf / policy, in the sentences above
19:27:01 <luke-jr> jeremyrubin: as with all maintainers, it's supposed to be janitorial
19:27:14 <luke-jr> running a script when there's review and consensus on a PR
19:27:20 <laanwj> fanquake: makes sense to me said like that
19:27:20 <bytes1440000> ariard: okay
19:27:24 <fanquake> i may have said validation in the proposed topic, but not specifically in this discussion
19:27:32 <fanquake> i did say she had worked on the code in validation
19:27:33 <sipa> Yeah, I prefer the role to be "mempool / rbf / policy" rather than validation.
19:27:54 <luke-jr> I'd drop "rbf" - seems like too minor a detail :p
19:28:15 <achow101> mempool/policy, components of which live in validation.cpp.. our naming sucks
19:28:33 <sipa> If we're bikeshedding, "mempool and transaction relay policy" ?
19:28:38 <jeremyrubin> i think it would make sense to draft a Job Description of what the appointment is for and scoping, and have people ack that when it exists.
19:29:00 <cfields_> jeremyrubin: that would've made sense for every prior nomination as well.
19:29:04 <jeremyrubin> yeah
19:29:04 <laanwj> the name can be more abstract it doesn't have to be precise a specfic cpp or so, we've never divided things up like that
19:29:05 <jeremyrubin> it would have
19:29:09 <ariard> sipa: sure, my thought was the mempool is a good candidate to get a maintainer in the coming years, if the complexity keeps increasing
19:29:10 <jeremyrubin> we probably should have done that
19:29:23 <Murch> mempool+policy sgtm
19:29:25 <jeremyrubin> as noted, i am not opposed to glozow having some set of responsibilities, it just doesn't seem like we're holding ourselves to a good standard to not do this
19:29:37 <glozow> Mempool / Policy is a scope I am fine with and plan to review anyway. Maybe we can one day more them out of validation.cpp if that's important to people. It seems the core question is whether or not people think I am knowledgeable enough to gauge whether a PR has enough review to be merged, since that's what a maintainer does.
19:29:50 <michaelfolkson> ack
19:29:57 <laanwj> glozow: i'm sure you are!
19:30:03 <luke-jr> sipa: policy affects more than relay in practice; and often relay isn't even given the priority
19:30:24 <ariard> jeremyrubin: yes, i agree we might do a Job Description to get the scoping right
19:30:33 <dongcarl> is fully in support of inverting the validation -> mempool dependency
19:30:46 <BlueMatt[m]> dongcarl: lol good luck
19:30:46 <cfields_> :)
19:30:50 <laanwj> we don't have that kind of precise scoping for maintainers, i don't think that's necessary
19:31:12 <luke-jr> glozow: IIRC you seemed confused about the relation between miners and relay policy; but I may be misremembering, and/or maybe cleared that up
19:31:13 <laanwj> we all have an idea what mempool+transaction relay is
19:31:15 <sipa> maintainers also learn, and responsibilities evolve
19:31:18 <achow101> tbh maintainers have merged things outside of their explicit scopes, and I don't think that's necessarily a bad thing
19:31:32 <dongcarl> I do like an "inclusionary" list of responsibilities, not an "exclusionary" one
19:31:42 <achow101> so long as every PR has been reviewed by multiple people and there is consensus for merging, it doesn't particularly matter who is merging
19:31:44 <laanwj> achow101: right, as long as there is agreement that's fine
19:31:45 <jeremyrubin> ok so then we aren't discussing adding gloria as a scoped maintainer, it's as a general maintainer?
19:31:56 <jeremyrubin> that seems like a different discussion, which is also OK to have
19:31:57 <MacroFake> Agree with achow101 and laanwj
19:32:00 <luke-jr> x.x
19:32:04 <achow101> jeremyrubin: all maintainers are basically general maintainers
19:32:13 <achow101> but have a focus
19:32:17 <laanwj> achow101: yes, that
19:32:32 <ariard> okay that might be the discussion, should we evolve towards scoped maintainance
19:32:45 <laanwj> i'm not sure
19:33:00 <luke-jr> I don't see that would improve things
19:33:05 <Murch> It's not like the parts of the codebases are that isolated
19:33:09 <sipa> i hope we don't need to have discussions about whether or not something was someone's purview to merge
19:33:18 <laanwj> sipa: +1
19:33:23 <sipa> the role is janitorial, as already pointed out
19:33:29 <laanwj> i don't think that has ever happened anyway, and probably shouldn't
19:33:47 <jeremyrubin> i think i would just like clarity -- you see how it is not good that gloria was proposed to be a scoped maintainer, everyone ACK'd that, and now it's backtracking into well it's always general purpose overall project maintenance?
19:33:56 <sipa> and i hope that the people given maintainer responsibilities are expected to judge their own expertise in making that decision
19:33:57 <jeremyrubin> Adding a maintainer is a serious, important thing
19:34:16 <bytes1440000> +1
19:34:17 <jeremyrubin> so I think as a project we should communicate more clearly about what exactly is being done and expected
19:34:28 <jeremyrubin> and if people are ACK voting, they should know what for
19:34:34 <MacroFake> jeremyrubin: It would be suspicious if glozow went out and merged a ton of build system changes that are reviewed, but not by her
19:34:37 <laanwj> i don't think that's necessary, but feel free to write something up if you want
19:34:49 <cfields_> jeremyrubin: as has adding every past maintainer. I think if you're going to call for procedural changes, you need to make it clear why this one's different.
19:34:51 <MacroFake> However, if she decides to work on the build system in 2 years, that should be reasonable
19:35:06 <jeremyrubin> cfields_ i have been asking for maintainers to give more clarity for a while
19:35:14 <jeremyrubin> so i am not personally departing from any prior stance
19:35:36 <luke-jr> jeremyrubin: people want to spend time on code, not necessarily process
19:35:39 <luke-jr> at least myself
19:35:44 <laanwj> luke-jr: +100
19:36:11 <dongcarl> I'm ACKing for glozow to be focused on mempool / policy but have the ability to act in a general maintainer way as long as it's not repeatedly unilaterally stepping on other maintainers' toes
19:36:25 <achow101> ^ that
19:36:38 <sipa> dongcarl: +1
19:37:26 <laanwj> sure, i mean given that she even wants that
19:37:29 <glozow> Thank you dongcarl. I agree to "be focused on mempool / policy but have the ability to act in a general maintainer way as long as it's not repeatedly unilaterally stepping on other maintainers' toes."
19:37:47 <ariard> from my viewpoint, the worthiness of a scoped maintainership is when you have a security issue to talk about you know at least whom should be the default interlocutor (even if I know we have a catch-all mailist endpoint)
19:38:10 <laanwj> that also works for semi-scoped
19:38:18 <Murch> Well, I'd have rephrased the second half of that to, and "expect to judge their own expertise in making merge decisions" as mentioned by Pieter above
19:39:03 <jeremyrubin> i want to spend time on a beach with a pina colada -- however, process work is a part of the development of the "bitcoin core organization", so you can't just stick your head in the sand and ignore it, especially when it comes to doling out commit access
19:39:08 <laanwj> if there's some urgent issue you talk to the person who has the focus on a certain area
19:39:40 <laanwj> no, i don't think adding more bureaucracy and formality makes things better
19:40:30 <luke-jr> there is no bitcoin core organization
19:40:41 <ariard> yeah, the "who has the focus on a certain area" might not always be clear, and it's more then whom you should nudge to get covert a fix done
19:41:22 <MacroFake> As a general rule, if you have an idea to improve the process, suggestions are welcome.
19:41:22 <sipa> As the project grows, some form of process/organization is expected to come into play. Until a few years ago, maintainers had barely any focus, let alone a well-defined focus. I think it suffices to talk about maintainers with a focus: people who have maintainer rights, but are expected to mostly focus on one aspect.
19:41:44 <sipa> Let's not rush adding more formality to this, it's already burdensome enough.
19:41:48 <laanwj> yes
19:42:11 <dongcarl> That sounds right to me!
19:42:22 <jeremyrubin> how burdensome is it to write a simple Job Description describing what "mempool / policy / validation / RBF" is so that we know what the focus actually is of the proposed new maintainer?
19:42:40 <michaelfolkson> I think being willing and available to discuss a controversial merge decision on IRC is important. Beyond that every PR has its own subtleties
19:42:56 <dongcarl> jeremyrubin: EPARSE
19:43:07 <laanwj> i think you're dragging things out now jeremyrubin
19:43:28 <laanwj> any other topics?
19:43:39 <ariard> anyway, i think a mempool maintainer is a good thing and I think glozow is a valuable candidate, however maybe we could take more time to think about the effective scope and if we have other candidates interested (again: i'm not interested)
19:44:31 <luke-jr> jeremyrubin: so write it yourself and propose it for merging to project docs in a PR
19:44:39 <dongcarl> I have a small implementation detail thing that's probs not important enough for the meeting but would like to chat a bit afterwards
19:44:48 <jeremyrubin> perhaps I am dragging it out -- i would fire back that you're avoiding important discourse on accountability of maintainers, something that you shouldn't shy away from in general. All maintainers should be able to produce 5 sentences on what areas they are focused on.
19:45:03 <cfields_> jeremyrubin: not 6?
19:45:10 <jeremyrubin> gotta start somewhere
19:45:27 <michaelfolkson> Regardless the work Gloria has done on mempool, policy, package relay, PR review club is great. This discussion isn't Gloria related, just process questions
19:45:36 <laanwj> sigh
19:45:53 <bytes1440000> ariard: +1 will be interesting to see if others are also interested to be a maintainer for different things
19:45:56 <dongcarl> I think "mempool / policy" is quite clear
19:46:08 <cfields_> bytes1440000: stop.
19:46:16 <achow101> jeremyrubin: how specific do you want this description to be? I find "mempool / rbf / policy" to be clear in scope
19:46:18 <jeremyrubin> generally the more the better -- achow101 has done a good  job detailing his course of action / wallet priorities IMO
19:46:45 <achow101> per file? per line? The codebase is complex enough that a PR in one area still has effects on code in other places that are "out of scope"
19:47:08 <luke-jr> echos laanwj's sigh
19:47:10 <instagibbs> If I'm made policy maintainer, I'll make sure the snack bar is refilled on consistent intervals
19:47:16 <bytes1440000> cfields_ : are people not allowed to respond in this channel?
19:47:18 <luke-jr> lol
19:47:19 <jeremyrubin> i don
19:47:47 <jeremyrubin> i don't find that to be sufficiently descriptive personally
19:48:02 <luke-jr> imagines instagibbs flying around the world to each dev's office to refill snacks
19:48:25 <laanwj> hehe
19:49:03 <jeremyrubin> glozow is it a problem to write up your intended focus areas and prioritizations for the project?
19:49:33 <laanwj> if she wants to write something up that's fine ofc
19:49:33 <glozow> jeremyrubin: I'm sure people have varying ideas of what amount of prioritizing or "roadmapping" would be appropriate, but I did prepare a list of things I consider important and would work on https://gist.github.com/glozow/5b8cfa27945371921dfe4d99b17e0424
19:49:43 <sipa> FWIW, I think it's a good idea in general for everyone (not just maintainers) to talk about their priorities and current focus.
19:49:46 <MacroFake> jeremyrubin: I'd say a personal roadmap is different from the tasks of a maintainer
19:49:47 <jeremyrubin> for example, achow101 has made docs like this https://achow101.com/2020/10/0.21-wallets
19:50:12 <jeremyrubin> MacroFake: i think that's a theoretical distinction
19:50:26 <jeremyrubin> practically, maintainers work on what they are interested in.
19:50:36 <luke-jr> jeremyrubin: achow101 is great at community/social publication of his work efforts; but that doesn't mean it needs to become a standard everyone has to abide by
19:50:55 <jeremyrubin> everyone doesn't get to be a maintainer either
19:50:56 <laanwj> it isn't a theoretical distinction only, as maintainer you're not supposed to only merge what you're working on yourself
19:51:05 <luke-jr> jeremyrubin: it's a responsibility, not a privilege
19:51:07 <instagibbs> I guess the question is what is the writeup for, who is the audience
19:51:10 <ariard> glozow: I think that's a good start, maybe open a GH issue, I would be interested to feed thoughts there and roll the ball forward on mempool maintenance
19:51:30 <sipa> The role of maintainers, jointly, is merging PRs that are ready. The question of focus is mostly about determining who among them is best placed to judge a particular PR's status.
19:51:42 <laanwj> sipa: right!
19:52:33 <fanquake> ariard: I think issues for specific topics would be fine. Although not a single catch-all for discussion of the entire contents of that gist
19:53:02 <jarolrod> i dont think glozow has to do all of these write-ups, we know what she works on and the idea of what she will be maintaining is fairly clear
19:53:05 <ariard> I would say we're missing few folks who has spent time on the mempool recently at that meeting: darosior, realtbast, jamesob and maybe few others L2 devs, they might have thoughts on mempool maintenance
19:53:26 <laanwj> ariard: agree, we don't take final descisions in meetings anyway
19:53:30 <ariard> fanquake: yeah anything to have more visibility on what are people interested with and allocate review time would be great
19:53:41 <luke-jr> ^
19:53:45 <jeremyrubin> glozow ariard +1 -- it's a good start
19:54:11 <jeremyrubin> laanwj: ah, what is the process then for decision on maintainership then?
19:54:17 <jeremyrubin> I thought it was being decided here
19:54:20 <laanwj> jeremyrubin: i'm done arguing process with you
19:54:21 <achow101> ariard: yes, we let people see the pr to add the merge key for a few days / weeks before actually merging it and granting rights
19:54:35 <luke-jr> jeremyrubin: btw, just to be clear, do you have any reservations with glozow merging PRs with the same expectations for maintainers in general?
19:54:40 <jeremyrubin> well you just said "ariard: agree, we don't take final descisions in meetings anyway"
19:55:03 <achow101> ack/nack on the merge key pr is the "final decision"
19:55:05 <fanquake> because nothing is actually done until a pr has been open, reviewed, merged
19:55:06 <laanwj> but it's prbably good to let some time pass so people can bring up potential issues they have with glozow being maintainer, or proposed alternatives
19:55:20 <jarolrod> ^ laanwj agree
19:55:32 <luke-jr> there can always be multiple maintainers - I don't know that alternatives are an objection
19:55:47 <laanwj> no, that's true
19:55:53 <jeremyrubin> laanwj: if you can't civilly discuss what process in your decision making you're not suited to be a maintainer... accountability is part of the job.
19:56:13 <laanwj> jeremyrubin: not everything is about your opinions
19:56:20 <jeremyrubin> i never said it is
19:56:32 <jeremyrubin> but you're trying to quash a relevant discussion for what reason?
19:56:33 <laanwj> jeremyrubin: you keep stating your preferences as some kind of facts that is very annoying to me
19:57:03 <instagibbs> I'm just going to venture that continuing this isnt helping
19:57:10 <michaelfolkson> +1
19:57:17 <jeremyrubin> i'm sorry to have annoyed you?
19:57:21 <ariard> jeremyrubin: i think accountability of maintainers is an interesting topic, however i think it's better to talk about it in a chill venues like coredev or on the mailing list, there is a lot of context IRC might not be the best medium
19:57:41 <achow101> jeremyrubin: you've been around long enough to see multiple people receive (and renounce) maintainership, I'm surprised that you are not already aware of the process.
19:57:45 <glozow> I care about the health of mempool/policy and Bitcoin Core, and I take it very seriously so I'm happy to be held to a high standard. All of the work we do is  entirely in public, so you are always free to audit me, tell me I've done something wrong, or request I prioritize other things. If you want to test my knowledge or preparedness, please let me know what the standard is beforehand and apply it equally to everyone in the same role.
19:58:09 <ariard> achow101: sgtm, to have a PR open for a while and see if we have any objections, I think it's worhty to have a discussion there or elsewhere on the scope
19:58:11 <jeremyrubin> glozow: +1
19:59:34 <jeremyrubin> re luke-jr: I'd probably want to have a 1-1 convo with gloria about her views on general maintainership before i'd personally endorse, but I don't have a nack presently
20:00:19 <cfields_> in that case i think we can continue without jeremyrubin's endorsement.
20:00:29 <laanwj> time is up, closing the meeting
20:00:33 <laanwj> #endmeeting