19:00:45 #startmeeting 19:00:45 Meeting started Thu Dec 5 19:00:45 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:49 Hi 19:00:49 hi 19:00:51 hi 19:00:54 hi 19:00:57 Hi 19:01:23 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr 19:01:25 jeremyrubin lightlike emilengler jonatack 19:01:32 Hi 19:01:38 hi 19:01:41 hi 19:01:45 hi 19:01:54 hi 19:01:58 hi 19:02:05 one proposed topic today in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : GUI CLI Arg test framework 19:02:06 Is that name list growing? Bunch of names I don't recognise 19:02:14 Hi 19:02:19 it's always growing 19:02:33 I tend to add everyone that has ever said anything in a meeting 19:02:46 Lol 19:02:48 append only 19:02:53 hi 19:02:59 short proposed topic: announcement of the new mailing list host, new process if you want new dev or announce lists 19:03:10 "short" 19:03:34 thanks, let's start with the usual 19:03:38 Ok 19:03:39 #topic High priority for review 19:03:59 https://github.com/bitcoin/bitcoin/projects/8 8 blockers, 6 chasing concept ACK 19:04:01 I want to add #16702 if that’s possible. 19:04:03 https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub 19:04:19 hi 19:04:33 [19:02:05] < wumpus> one proposed topic today in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : GUI CLI Arg test framework 19:04:45 (oops, sorry). also hi 19:04:51 hi! 19:04:58 Yeah I wanna talk about my proposed topic there^^ 19:05:04 Would cover it now if it would be possible 19:05:11 #17621 is a fix for the avoid_reuse leak, at least looking for concept ACKs 19:05:13 https://github.com/bitcoin/bitcoin/issues/17621 | IsUsedDestination should count any known single-key address by instagibbs · Pull Request #17621 · bitcoin/bitcoin · GitHub 19:05:20 (already on list) 19:06:00 added 16702 19:06:28 instagibbs: should it be under "chasing concept ACK" then instead of blockers? 19:06:34 yeah actually 19:06:37 Thank you! 19:07:01 Doesn't need to go on the list, but #17663 is going to be the base of a bunch of other PRs, if build system people want to take a look. 19:07:03 https://github.com/bitcoin/bitcoin/issues/17663 | build: pass -dead_strip_dylibs to ld on macOS by fanquake · Pull Request #17663 · bitcoin/bitcoin · GitHub 19:07:59 escalating ever scarier linker argument names 19:08:27 hah 19:08:36 -Wl,-why_live has been getting some use today as well heh 19:08:54 lol 19:08:58 heh 19:09:00 #topic GUI CLI Arg test framework (emilengler) 19:09:10 Yes so let me first talk about it 19:09:46 I made a PR a few day ago "Add -guisettings" (Can someone post the id? I'm on my phone). Tests were suggested for it because it adds a cli paramter 19:10:08 #17636 19:10:09 And there are Qt only cli parameters. I was wondering if it would be worth writing a test framework for qt args as well 19:10:10 https://github.com/bitcoin/bitcoin/issues/17636 | qt: Add -guisettings option by emilengler · Pull Request #17636 · bitcoin/bitcoin · GitHub 19:10:15 If it is possile to test then 19:10:20 instagibbs: thanks 19:10:53 why is this a question? isn't testing things always good? what's the small print? 19:11:53 wumpus: Good question but it would be some effort und probably a bit maintaince as well and I don’t know if it is actually worth to make a new framework (or heavily extend the current one) just for one extra parameter 19:11:57 I guess GUI things are hard to test in general 19:12:16 well what would it be testing? 19:12:23 like 'does the window start minimized' is not that easy to measure 19:12:28 right 19:12:33 sipa: It would test if a file is created 19:12:40 that sounds easy 19:12:52 probably doesn't need much of a "framework" at all 19:12:59 ryanofsky would like to know your thoughts if you are here 19:13:03 that's just anbother functional test riight 19:13:07 Given you are doing the settings refactoring 19:13:10 wumpus: Maybe we could add an extra qt parameter which makes some stdout. This is then getting parsed 19:13:40 wumpus: IIRC the current functional test framework is bitcoind only 19:13:48 anyhow, yes, testing GUI arguments would be nice, some are more realitic for automatic testing than others 19:14:22 Yes, things like -splash are probably impossible to test 19:14:24 you can run the currrent functional tests w/ bitcoin-qt 19:14:32 but yes, that one would be bitcoin-qt only 19:15:15 Ok still thanks for the clarification :). Things I wanted to say are done. Someone wants to say something about it? 19:15:20 Otherwise this topic would be done 19:15:28 let's go to warren's topic then 19:15:36 emilengler: i don't know what exactly you're asking 19:15:42 #topic announcement of the new mailing list host (warren) 19:15:51 I must express apologies for the unexpected timing of transition of lists.linuxfoundation.org to a new host. Dealing with this for the past years has been stressful, evaluated alternatives were all found to have drawbacks and communications between parties has been slow. Oddly enough by not changing we ended up with the best outcome. After a brief service disruption due to misconfiguration the lists were back online later that day. End 19:15:51 result: 19:15:59 - No change to list addresses or archive URL's. 19:15:59 - The new host is cooperative, communicative and will properly maintain the mailing list server. 19:16:06 - New dev or announce lists can now be requested. For example bitcoin-knots-announce was created. I will put a policy on a webpage somewhere but it will be roughly: "This list server is for only FOSS and strongly preferred to be pertaining to open common infrastructure, specifications or standards. If you want lists for a niche or commercial project you probably should instead use Google Groups or something." 19:16:13 I must thank the Linux Foundation for years of politically neutral hosting of dev lists, and now the Oregon State University Open Source Lab (OSUOSL) for continued vendor neutral hosting. The OSUOSL is well known since the early 2000's for infrastructure support for thousands of Open Source projects. 19:16:16 fin 19:16:17 next 19:16:27 unless people have questions, but this isn't really a dev topic so just FYI 19:16:34 thanks warren! 19:16:37 thanks for the update 19:16:43 Thanks 19:16:45 and for all the time it took to get there :) 19:16:47 thanks warren! 19:17:18 there was some talk of changing the bitcoin-core-dev mailing list to an announcement list 19:17:30 as, effectively, that's what it is 19:17:52 is anyone on it? 19:18:23 I have no idea, if not, I can stop doing announcements there 19:18:24 I suppose that's a simple change. Also consider if dev would like special interest group dev lists or other announce lists. 19:19:03 i think for non-mailinglist aliases we can use @bitcoincore.org fine 19:19:07 wumpus: I can ask for subscriber statistics, in any case it's helpful to keep posting to the same place because the archives are in a well known location that won't change anytime soon 19:19:36 there was vaguely some interest in it as announcement list, let me see if I can find the bitcoincore.org PR 19:19:55 https://github.com/bitcoin-core/bitcoincore.org/pull/648 19:20:10 In past years the mailing list host was not cooperative, that's different now so we can make changes like this. 19:20:31 at the least, we don't need a discussion mailing list for bitcoinc core, but a mailer for version and RC announcements is useful 19:20:42 (as well as archive) 19:21:00 one consideration is the archive URL is well known and linked from elsewhere so we'd need redirects if it renames 19:21:02 cool :) 19:22:06 we can discuss that outside the meeting 19:22:09 any other topics? 19:22:15 thanks warren. OSUOSL appears to be a great choice. 19:22:16 hey can I get #16426 on hp? 19:22:19 https://github.com/bitcoin/bitcoin/issues/16426 | Reverse cs_main, cs_wallet lock order and reduce cs_main locking by ariard · Pull Request #16426 · bitcoin/bitcoin · GitHub 19:22:25 ariard: you're too late ! 19:22:30 no, ofc 19:22:43 wumpus: sorry wasn't there 19:22:51 it might be a slight IBD improvement 19:22:51 FYI: This was discussed in the PR club yesterday iirc 19:23:01 ariard: blockers or chasing concept? 19:23:06 due to not locking cs_main in BlockConnected/BlockDisconnected 19:23:11 it's ready it pass all tests 19:23:20 and got already a lot of concept acks 19:23:46 hard commit is only the top one, because you need to invert lock order at once 19:23:47 ok added 19:23:59 but I can still split the PR if people feel it's too much at once 19:24:03 (to blockers, then) 19:24:08 thnaks 19:24:56 that concludes the meeting, I think 19:25:11 #endmeeting