19:00:17 <laanwj> #startmeeting 19:00:47 <jeremyrubin> hi 19:00:51 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard 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 lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos 19:00:53 <laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 19:00:56 <achow101> hi 19:01:00 <laanwj> no bot today, apparently 19:01:04 <michaelfolkson> hi 19:01:05 <darosior> hi 19:01:11 <jarolrod> Hi 19:01:13 <meshcollider> hi 19:01:19 <hebasto> hi 19:01:48 <kvaciral[m]> hi 19:01:59 <laanwj> doesn't look like any topics have been proposed for this week (use #proposedmeetingtopic to propose topics you want to discuss in the meeting) 19:02:01 <laanwj> any last minute ones? 19:02:39 <laanwj> i think we should cancel the IRC meeting next week due to the IRL coredev meeting 19:02:49 <jeremyrubin> disagree 19:03:10 <jeremyrubin> i'd like to move some things onto blockers 19:03:14 <jeremyrubin> err priority 19:03:26 <laanwj> well, i'm not going to chair it, feel free to meet anyway 19:03:33 <jeremyrubin> kk 19:03:54 <jeremyrubin> also won't be at IRL i think :( 19:04:04 <jeremyrubin> #topic high priority for review 19:04:08 <laanwj> eh, 19:04:20 <laanwj> please leave that to me 19:04:37 <jeremyrubin> laanwj: "well, i'm not going to chair it, feel free to meet anyway" 19:04:44 <laanwj> jeremyrubin: next week 19:04:44 <cfields> hi 19:04:58 <jeremyrubin> slaps forehead 19:05:00 <laanwj> i'm here now why wouldn't i 19:05:02 <michaelfolkson> You can always request things are moved to blockers outside an actual meeting right laanwj? 19:05:06 <jonatack> hi 19:05:08 <cfields> hehe 19:05:09 <laanwj> michaelfolkson: yes, sure 19:05:20 <michaelfolkson> Wouldn't need a meeting next week if that is all jeremyrubin wants to do 19:05:21 <laanwj> anyhow, yes, high priority for review 19:05:24 <jeremyrubin> sorry for the read-o, i thought you were saying cancel right now 19:05:40 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 9 blockers, 2 chasing concept ACK 19:06:14 <laanwj> anything to add/remove or that is almost ready for merge? 19:06:25 <fjahr> hi 19:06:40 <darosior> #22539 can be removed now it was merged (thanks laanwj for looking at it today btw) 19:06:42 <gribble> https://github.com/bitcoin/bitcoin/issues/22539 | Re-include RBF replacement txs in fee estimation by darosior ÷ Pull Request #22539 ÷ bitcoin/bitcoin ÷ GitHub 19:06:52 <michaelfolkson> #22950 is merged too 19:06:54 <gribble> https://github.com/bitcoin/bitcoin/issues/22950 | [p2p] Pimpl AddrMan to abstract implementation details by amitiuttarwar ÷ Pull Request #22950 ÷ bitcoin/bitcoin ÷ GitHub 19:07:02 <lightlike> 22950 and 20487 were also merged 19:07:37 <jeremyrubin> i'd like to put #21702 as my high priority -- up to you on removing the other one currently my priority 19:07:39 <gribble> https://github.com/bitcoin/bitcoin/issues/21702 | Implement BIP-119 Validation (CheckTemplateVerify) by JeremyRubin ÷ Pull Request #21702 ÷ bitcoin/bitcoin ÷ GitHub 19:08:22 <laanwj> thanks, removed the merged ones, 7 blockers, 1 chasing concept ACK left 19:08:25 <jonatack> among the open ones, i'd like to suggest #22702 and #21943 to reviewers, please have a look if you have some bandwidth 19:08:27 <gribble> https://github.com/bitcoin/bitcoin/issues/22702 | Add allocator for node based containers by martinus ÷ Pull Request #22702 ÷ bitcoin/bitcoin ÷ GitHub 19:08:30 <gribble> https://github.com/bitcoin/bitcoin/issues/21943 | Dedup and RAII-fy the creation of a copy of CConnman::vNodes by vasild ÷ Pull Request #21943 ÷ bitcoin/bitcoin ÷ GitHub 19:09:03 <michaelfolkson> A new soft fork is high priority? 19:09:13 <laanwj> jeremyrubin: added 19:09:18 <cfields> "for review" 19:09:44 <jeremyrubin> michaelfolkson: well, high priority is for communicating personal priority + review precedence. afaiu contributors get to pick what they want there 19:09:51 <jonatack> the first for performance and lower memory use, the second appears to reduce some of the most frequent lock contentions 19:10:28 <laanwj> jonatack: intend to look into them 19:11:33 <laanwj> anything else? 19:12:27 <jonatack> laanwj: great! 19:12:30 <laanwj> nothing else to add to high prio? no other topics? 19:12:50 <meshcollider> We could re-visit the discussion about fanquake now we have a lot of ACKs :) 19:13:28 <jeremyrubin> Is this about increased GH permissions? 19:13:30 <michaelfolkson> What's your best case for the timing of a #21702 merge jeremyrubin? It is an interesting time to put it as your highest priority for review 19:13:32 <gribble> https://github.com/bitcoin/bitcoin/issues/21702 | Implement BIP-119 Validation (CheckTemplateVerify) by JeremyRubin ÷ Pull Request #21702 ÷ bitcoin/bitcoin ÷ GitHub 19:13:58 <meshcollider> jeremyrubin: yep 19:14:06 <michaelfolkson> Perhaps not the best place for this discussion, probably mailing list is better 19:14:12 <michaelfolkson> For the PR 19:14:19 <michaelfolkson> fanquake discussion sounds good 19:15:31 <michaelfolkson> I think there were a lot of ACKs with two NACKs (from what I saw) 19:15:42 <laanwj> didn't keep a tally but a lot of people voted +1 for fanquake being able to block people from the github, outside the meeting 19:15:44 <laanwj> yes 19:15:52 <meshcollider> FWIW, we had 15 ACKs (darosior, michaelfolkson, jarolrod, fjahr, MarcoFalke, laanwj, dhruv, jnewbery, amiti, ariard, larryruane, sipa, achow101, hebasto, and myself) on IRC in support, while only 2 against (prayank, luke-jr) 19:16:17 <laanwj> meshcollider: ok! 19:16:28 <jeremyrubin> i'll ack --> perhaps we can just keep a log wiki somewhere of who is blocked and why 19:16:41 <luke-jr> laanwj: I don't think the problem is him being able to block spammers, just having full access 19:17:03 <meshcollider> jeremyrubin: I think the only thing anyone is ever blocked for is unintelligible spam 19:17:08 <laanwj> to be clear, we only block, ever, for obvious spamming and scamming attempts 19:17:22 <luke-jr> meshcollider: I've seen a lot of issues locked to stop non-spam discussion lately 19:17:22 <jeremyrubin> that's fine then, email notification are sufficient IMO 19:17:28 <luke-jr> (but not sure that's fanquake) 19:17:37 <luke-jr> laanwj: that isn't accurate 19:17:49 <meshcollider> luke-jr: I haven't seen that, you'll need to provide specific examples 19:17:54 <luke-jr> unless the distinction is lock vs block 19:18:16 <laanwj> luke-jr: i mean block as in making specific users unable to post or PR to the repository 19:18:16 <luke-jr> meshcollider: I'll bring them up next time; IIRC the last one I noticed was rebroad commenting 19:18:30 <luke-jr> rebroad may be dense sometimes, but he isn't spam 19:18:39 <laanwj> rebroad isn't blocked from the repo !!! 19:19:01 <laanwj> you're bringing other things into this 19:19:10 <bitcoin-git> [bitcoin] dougEfresh opened pull request #23224: [RFC] util: Add suffix byte unit parser for ArgsManager (master...add-args-byte-units) https://github.com/bitcoin/bitcoin/pull/23224 19:19:44 <michaelfolkson> I would like more transparency and explanations on why certain issues are locked (if people ask) 19:19:45 <luke-jr> ok, sorry for the confusion 19:19:59 <michaelfolkson> But I don't think that is fanquake specific 19:20:02 <lightlike> luke-jr: the locking of old PRs was done by MacroFalke, see 2021-10-05 09:57 in logs 19:20:18 <jamesob> (ACK fanquake, fwiw) 19:20:22 <laanwj> i think the idea is that people open new issues instead of post on ancient ones 19:20:41 <michaelfolkson> Recently MarcoFalke closed 3 year old issues and told this channel (which was fine I think) 19:20:55 <michaelfolkson> As long as this channel is told and people can enquire why if there is confusion 19:21:03 <laanwj> e.g. some old issues and PRs that have been merged years ago keep accumulating replies that don't really apply to the original topic anymore 19:21:09 <meshcollider> michaelfolkson: He didn't close them, he locked inactive issues which were already closed I think 19:21:32 <michaelfolkson> meshcollider: Ok sure, thanks for correction 19:21:34 <laanwj> right 19:22:13 <laanwj> in any case i think it makes sense to post why before closing/locking an issue, i tend to to that unless it's obvious 19:22:21 <meshcollider> (locking issues is also a lower permission than maintainer, a number of other users have that permission) 19:22:37 <meshcollider> The "issue management" team 19:22:45 <laanwj> right 19:23:32 <laanwj> in any case, if your pR or issue is closed and you disagree, bring it up here 19:24:02 <jeremyrubin> maybe we should just declare issue/pr bankruptcy and close everything w/o activity in the last week and allow folks to reopen if they want, that way there's less 'moral judgement' of should be closed or not and we can just clean shop 19:24:16 <laanwj> doing issue management is simply needed in a busy project like this, and i'm sure there are mistakes sometimes 19:24:34 <meshcollider> jeremyrubin: if an issue is closed by a maintainer I don't think the user can re-open it themselves 19:25:32 <jeremyrubin> we could do a 'reopen bot' that checks for a request to reopen as a comment... but i know that's extra work for someone 19:25:40 <laanwj> why would that need a bot 19:25:45 <laanwj> simply ask a maintainer when it happens 19:25:49 <laanwj> or better, simply post here 19:26:05 <jeremyrubin> didn't want to make more work for maintainer as noted by meshcollider, but I agree that works 19:26:09 <jonatack> meshcollider: seems so, i've had pulls unilaterally closed several times this year and had to open a new pull 19:26:49 <luke-jr> jeremyrubin: not all of us have funding to touch every PR once a week; sometimes it takes me months to address things 19:26:59 <laanwj> jonatack: why didn't you ask to reopen them? 19:27:22 <meshcollider> ^ 19:27:41 <jonatack> laanwj: wu wei, going with the flow i guess :D 19:27:43 <jeremyrubin> luke-jr: i'm saying do it as a 1x pr-bankruptcy, not every week. (maybe 1x a year?) 19:28:11 <michaelfolkson> It seems communication could be improved in both directions between PR authors and maintainers :) 19:28:23 <michaelfolkson> Definitely ask next time jonatack :) 19:28:31 <meshcollider> I think this is a very separate conversation anyway 19:28:32 <laanwj> jonatack: heh 19:28:57 <jonatack> i mean, it's not important, just confirming meshcollider's statement 19:31:19 <laanwj> i think that concludes the meeting 19:32:13 <laanwj> luke-jr: in your case we know that, it's sometimes different with new contributors that open a PR then never respond again :) 19:32:52 <laanwj> #endmeeting