19:00:19 <laanwj> #startmeeting 
19:00:20 <core-meetingbot`> Meeting started Thu Mar 24 19:00:19 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:20 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:28 <fanquake> hi
19:00:31 <hebasto> hi
19:00:34 <larryruane> Hi
19:00:36 <michaelfolkson> hi
19:00:40 <stickies-v> hi
19:00:40 <achow101> hi
19:00:57 <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:00:58 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:01 <MarcoFalke> hi
19:01:02 <dongcarl> hi
19:01:04 <sipsorcery> hi
19:01:06 <cfields_> hi
19:01:20 <laanwj> hello everyone, welcome to the weekly general #bitcoin-core-dev meeting
19:01:29 <sipa> hi
19:02:01 <laanwj> two topics have been proposed: Current thinking on when to deprecate and the deprecation process when deprecation is considered appropriate (michaelfolkson) and RC23.0 Testing Guide update (stickes-v)
19:02:17 <lightlike> hi
19:02:17 <laanwj> any last minute ones?
19:02:27 <michaelfolkson> Please do stickies-v topic first
19:03:24 <laanwj> michaelfolkson: ok, well, we'll start with high priority for review dsicussion as usual then stickies-v topic
19:03:32 <michaelfolkson> Of course, yup
19:03:34 <laanwj> #topic High priority for review
19:03:34 <core-meetingbot`> topic: High priority for review
19:04:02 <laanwj> https://github.com/bitcoin/bitcoin/projects/8  10 blockers, 1 chasing concept ACK
19:04:24 <laanwj> anything to add, remove, or that is almost ready for merge?
19:05:17 <kanzure> hi
19:05:21 <dongcarl> "almost ready for merge" as in "already on the list and almost ready for merge"?
19:05:43 <laanwj> dongcarl: yes, that's what i mean
19:05:56 <dongcarl> 👍
19:05:56 <laanwj> that said, you can mention PRs that should be merged any time whether on the list or not
19:06:13 <fanquake> I don't have a PR, but I'd propose #23083
19:06:14 <gribble> https://github.com/bitcoin/bitcoin/issues/23083 | rpc: Fail to return undocumented or misdocumented JSON by MarcoFalke · Pull Request #23083 · bitcoin/bitcoin · GitHub
19:06:15 <dongcarl> Got it, just checking! 😄
19:06:31 <MarcoFalke> fanquake: Good suggestion
19:06:39 <MarcoFalke> Though, I already have one on hi-prio
19:06:46 <MarcoFalke> (It's illegal to have two)
19:06:56 <fanquake> it can take the place of my PR
19:07:08 <fanquake> the amount of bugs it's found would warrant it
19:07:09 <dongcarl> 😮: https://github.com/bitcoin/bitcoin/pull/23083#issuecomment-1075037566
19:07:10 <laanwj> yes highly illegal !!!
19:08:13 <laanwj> MarcoFalke's other PR doesn't seem to have sufficient review yet to qualify for merging right now
19:08:21 <laanwj> but yes, fine
19:09:07 <laanwj> added
19:09:16 <MarcoFalke> blush
19:09:16 <laanwj> anything else?
19:10:57 <Murch> hi
19:11:28 <laanwj> if not, let's go to next topic
19:11:38 <laanwj> #topic RC23.0 Testing Guide update (stickies-v)
19:11:39 <core-meetingbot`> topic: RC23.0 Testing Guide update (stickies-v)
19:12:15 <stickies-v> As promised on last week’s meeting, I’d revert with an update on the RC23 testing guide, so first version available here: https://github.com/stickies-v/bitcoin-devwiki/blob/master/23.0-Release-Candidate-Testing-Guide.md . Please reach out any way you like with feedback and/or suggestions (too alpha for proofreading/typos though).
19:12:33 <stickies-v> I still need to add instructions on arm-arm64-apple-darwin (cc hebasto) and even though consensus last week was that the RPC updates weren't super crucial to test in this guide, I might add some instructions if I have time. I'm still very much open to further changes to test, so please let me know if I missed anything you consider important?
19:13:05 <laanwj> will take a look at it, thanks! do we need to add a link to it anywhere?
19:13:08 <jonatack> hi
19:13:22 <laanwj> i guess in  #24501 would make sens
19:13:23 <gribble> https://github.com/bitcoin/bitcoin/issues/24501 | v23.0 testing · Issue #24501 · bitcoin/bitcoin · GitHub
19:13:49 <stickies-v> it would, but I don't think it's ready for that yet, should be in a few days
19:14:00 <stickies-v> then I'll also need write access to bitcoindev-wiki to update, I think?
19:14:34 <laanwj> stickies-v: oh you don't yet?
19:14:45 <laanwj> no problem we'll get that sorted
19:15:07 <jeremyrubin> hi
19:15:26 <bitcoin-git> [bitcoin] jonatack opened pull request #24663: doc, init: add links to doc/cjdns.md (master...doc-cjdns) https://github.com/bitcoin/bitcoin/pull/24663
19:16:07 <stickies-v> ty! that's pretty much all from me, just wanted to update and encourage to reach out with ideas and feedback. thanks!
19:16:35 <laanwj> thanks for the update
19:17:23 <laanwj> #topic Current thinking on when to deprecate and the deprecation process when deprecation is considered appropriate
19:17:23 <core-meetingbot`> topic: Current thinking on when to deprecate and the deprecation process when deprecation is considered appropriate
19:17:33 <laanwj> (michaelfolkson)
19:18:07 <michaelfolkson> Ok so I went down this mini rabbithole on deprecation in Core this week due to https://github.com/bitcoin/bitcoin/issues/24638
19:18:50 <michaelfolkson> I was surprised that there was opposition to deprecating a RPC that appears to offer a subset of what another RPC offers
19:19:05 <laanwj> usually we keep to two major releases for deprecation (say, RPC APIs), but there are some things with which to be much more careful around, like the legacy wallet
19:19:53 <sipa> and it's always on a case-by-case basis weighing the benefits against the costs
19:19:58 <jeremyrubin> i think if it is truly a subset we can just shim one functionality with the other new code  and the overhead of having an RPC call itself is not huge
19:20:09 <laanwj> support for old wallets is really important for obvious reasons, so the upgrade path for that has to be completely water tight
19:20:10 <MarcoFalke> michaelfolkson: I'd say the process is (1) Decide on a case-by-case basis what should be deprecated (2) Decide on a case-by-case basis what should be deleted
19:20:13 <michaelfolkson> I tried to write up my current understanding on how Core approaches deprecation (whether to do it or not) https://bitcoin.stackexchange.com/questions/113008/what-are-the-considerations-when-assessing-whether-to-deprecate-a-feature-in-bit
19:20:14 <jeremyrubin> the benefit of deprecation is if the old way is truly broken somehow / leads to tons of extra code
19:20:43 <MarcoFalke> I don't think it makes sense to follow a strict process/timeline for deprecation/deletion
19:21:06 <laanwj> yes, it's a compromise on a case by case basis
19:21:07 <MarcoFalke> I even think that deletion is not mandatory for deprecated stuff
19:21:17 <jonatack> my understanding is roughly as expressed in https://github.com/bitcoin/bitcoin/pull/24606#issuecomment-1076377877
19:21:59 <michaelfolkson> The argument against having a timeline though is you don't give sufficient advance warning to users/downstream projects and creates issues that could be avoided. Presumably that is why achow101 has tried a timeline approach
19:22:12 <michaelfolkson> *argument for
19:22:26 <michaelfolkson> https://github.com/bitcoin/bitcoin/issues/20160
19:22:42 <MarcoFalke> For example, there is almost no cost to an alias RPC, so personally I don't see a reason to remove it: https://github.com/bitcoin/bitcoin/blob/e30b6ea194fee3bb95a45e7b732a99566b88f1f5/src/wallet/rpc/coins.cpp#L235
19:22:47 <sipa> Once we deprecate an RPC, the rule is generally 1 or 2 major releases.
19:23:10 <sipa> But I think the point is that there isn't a fixed timeline about things, because it's always a case-by-case situation.
19:23:31 <MarcoFalke> michaelfolkson: The timeline for the wallet already slipped, it is not something that users can rely on
19:23:51 <sipa> E.g. the discussion around removing BDB/legacy wallet support is a very different one than the one around removing the misleading "addresses" RPC output field in getaddressinfo.
19:24:24 <michaelfolkson> Right, I guess it is just about ensuring there is communication on what is planned
19:24:50 <sipa> I don't think there's much to say here; there are a number of approaches we've used in the past... some of those may or may not be appropriate for future changes.
19:25:13 <sipa> It all depends on what's on the line, and what is to be gained.
19:25:44 <jeremyrubin> one point in favour of deprecation for this, is that in theory if someone is using it and they're updating their logic they might be helped by learning about the new functionalities
19:25:45 <michaelfolkson> And nothing really to write up. Just case by case. The only thing that should maybe be done is communication on planned deprecation of legacy wallet
19:25:50 <MarcoFalke> reminds me of the "let's do a refactor-all-the-things week" discussion
19:26:11 <laanwj> oh no
19:26:59 <michaelfolkson> Staggered deprecations over multiple versions and good communication (mailing list, release notes etc) seem like good idea to me. But can't guarantee timelines
19:27:16 <michaelfolkson> Ok, there isn't much more to be said then
19:27:23 <laanwj> any other topics?
19:27:36 <jonatack> I agree with an ad hoc approach (in general)
19:27:49 <jonatack> for most of these kind of topics
19:30:22 <laanwj> if there's nothign more to discuss it's time to close the meeting, thanks everyone for attending
19:30:25 <laanwj> #endmeeting