19:00:59 <laanwj> #startmeeting 19:00:59 <core-meetingbot> Meeting started Thu Mar 31 19:00:59 2022 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings. 19:00:59 <core-meetingbot> Available commands: action commands idea info link nick 19:01:02 <achow101> hi 19:01:21 <fanquake> hi 19:01:23 <sipa> hi 19:01:24 <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 larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball 19:01:26 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild 19:01:28 <sipsorcery> hi 19:01:38 <hebasto> hi 19:01:42 <cfields> hi 19:01:52 <laanwj> fanquake: i don't have the debug symbols handy for rc2 right now, but it should be possible to figure out where that is in the binary 19:02:18 <fjahr> hi 19:02:20 <laanwj> PSA: 23.0rc3 has been tagged, please start your guix builders :) 19:02:31 <jonatack85> hi 19:02:48 <laanwj> welcome to the weekly general bitcoin-core-dev meeting 19:03:00 <laanwj> there have been no pre-propsed meeting topics, any last minute ones? 19:05:23 <laanwj> ok, let's discuss high priority for review 19:05:31 <laanwj> #topic High priority for review 19:05:32 <core-meetingbot> topic: High priority for review 19:05:46 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 10 blockers, 1 chasing concept ACK 19:06:06 <Murch> hi 19:06:07 <laanwj> i'd reallly ask to review and test #22702 it would be good to get that in early in the release window 19:06:10 <gribble> https://github.com/bitcoin/bitcoin/issues/22702 | Add allocator for node based containers by martinus ÷ Pull Request #22702 ÷ bitcoin/bitcoin ÷ GitHub 19:06:30 <jonatack85> +1 for 22702, will do 19:06:53 <laanwj> anything to add, remove, or that is in the list and almost ready for merge? 19:07:57 <luke-jr> #24294 should probably be in the list 19:07:59 <gribble> https://github.com/bitcoin/bitcoin/issues/24294 | RPC: Switch getblockfrompeer back to standard param names blockhash and nodeid by luke-jr ÷ Pull Request #24294 ÷ bitcoin/bitcoin ÷ GitHub 19:09:16 <laanwj> luke-jr: added, though you have two in the list now 19:09:56 <luke-jr> oops, wrong list. I meant the 23.0 list 19:10:35 <luke-jr> sorry 19:11:26 <laanwj> ok 19:11:28 <jonatack85> luke-jr: i argued against that change in my review feedback there but agree there's something to be said for the principle of least surprise. so ~0 but in that case the developer notes about rpc argument naming should maybe be clarified 19:11:53 <laanwj> i've added it to 23.0 milestone, no opinion on the change really 19:12:11 <jonatack85> there's maybe also a question of naming consistency within an rpc, versus across rpcs 19:12:17 <luke-jr> I kinda see it as 23.0 or not worth the effort, myself 19:12:19 <laanwj> but agree that if it is to be changed back it needs to be before the release 19:12:45 <laanwj> otherwise it's another breaking change 19:14:38 <laanwj> anything else? any other topics? 19:14:53 <jeremyrubin> hi 19:16:16 <laanwj> there's something to be said for standardizing parameter names across RPCs, it's kind of annoying as user if every RPC has slightly different inconsistent spelling for the same thing 19:17:00 <laanwj> it's also a lot of work and may result in breaking changes in itself if persued too obsessively, so it's more of a best effort within the other constraints thing 19:17:48 <jeremyrubin> i am indifferent -- i don't think we have strong enough consistency in the RPCs right now that one more inconsistency hurts, if we want things to be really strongly consistent we should fix it all up in a big breaking API changes release. the worst case, IMO, is subtle small changes that might not get caught. better to just have nothing work than 19:17:49 <jeremyrubin> for things to seem to work. 19:18:09 <jeremyrubin> otoh, this seems like a good one since it's a reversion of an unecessary change 19:18:23 <glozow> hi 19:19:27 <laanwj> jeremyrubin: right, for new RPCs it makes sense to choose a parameter name already used by other RPCs for a same thing instead of trying to come up with something cleverer 19:19:48 <laanwj> i definitely agree absolute consistency is not a goal let that be clear 19:20:51 <laanwj> anyhow, any other topics? 19:22:10 <laanwj> #endmeeting