19:00:58 <laanwj> #startmeeting 
19:01:08 <jarolrod> Hi
19:01:11 <achow101> hi
19:01:13 <hebasto> hi
19:01:25 <jonatack> hi
19:01:31 <furszy> hi
19:01:46 <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:48 <laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:01:49 <lightlike> hi
19:01:56 <laanwj> welcome to the weekly bitcoin-core-dev meeting
19:01:57 <ajonas> Hi
19:02:05 <cfields> hi
19:02:07 <vasild> hi
19:02:08 <fanquake> hi
19:02:31 <michaelfolkson> hi
19:02:51 <laanwj> there have been two proposed meeting topics: 2022-08-11 21:32:46     hebasto #proposedmeetingtopic CMake-based build system (pr25797)   2022-08-12 18:00:23     vasild  #proposedmeetingtopic vasild for a new maintainer with a focus on P2P/networking
19:03:13 <sipa> hi
19:04:03 <laanwj> might also make sense to discuss for the 24.0 milestone (instead of high priority for review)
19:04:53 <laanwj> #topic 24.0 milestone
19:04:54 <core-meetingbot> topic: 24.0 milestone
19:04:59 <Murch> hi
19:05:02 <sipsorcery> hi
19:05:13 <fanquake> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A24.0
19:06:15 <laanwj> anything to add/remove there?
19:06:18 <sipa> #25717 is getting closer I think, with some discussed additions added (progress bar/logging), and some complexity removed and postponed to future changes if desired
19:06:21 <gribble> https://github.com/bitcoin/bitcoin/issues/25717 | p2p: Implement anti-DoS headers sync by sdaftuar · Pull Request #25717 · bitcoin/bitcoin · GitHub
19:07:00 <laanwj> great!
19:08:03 <laanwj> ok if nothing else, let's move to next topic
19:08:34 <laanwj> #topic CMake-based build system (hebasto)
19:08:34 <core-meetingbot> topic: CMake-based build system (hebasto)
19:08:38 <hebasto> hi
19:08:41 <hebasto> #25797 proposes the introduction of a CMake-based build system (CM, for short).
19:08:43 <gribble> https://github.com/bitcoin/bitcoin/issues/25797 | build: Add CMake-based build system by hebasto · Pull Request #25797 · bitcoin/bitcoin · GitHub
19:08:48 <hebasto> The current benefits are outlined in the PR description.
19:08:55 <hebasto> As a reminder, the last such scale change was a switch from Gitian to Guix. The first Guix PR #15277 was in v0.19, but only v22.0 was the first Guix-built release.
19:08:57 <gribble> https://github.com/bitcoin/bitcoin/issues/15277 | contrib: Enable building in Guix containers by dongcarl · Pull Request #15277 · bitcoin/bitcoin · GitHub
19:09:02 <hebasto> As for Qt, the Bitcoin Core project packages a GUI, and the GUI is a part of Bitcoin Core. As such, the move to Qt6 will be inevitable. A big motivation for the work on this change is to accommodate for the move to Qt6.
19:09:08 <hebasto> A comment in PR mentioned "bells and whistles".
19:09:13 <hebasto> Here is my personal motivation disclosure.
19:09:20 <hebasto> It is highly likely that my grandchildren will be accessing the bitcoin network using GUI-enabled software. And I'll do my best to ensure that it will be Bitcoin Core.
19:09:25 <hebasto> Here are the suggested questions for discussion now
19:09:30 <hebasto> 1. Are we open for a CMake-based build system (CM) in general?
19:09:36 <hebasto> 2. What is the preferred way to get CM into the repository: (a) a single PR with 100% feature parity, or (b) a series of incremental PRs?
19:09:43 <hebasto> 3. How long the old build system and the new one should co-exist / be co-maintained: (a) forever, (b) some release cycles, (c) switch from old to new at once?
19:09:52 <hebasto> that is it, let's discuss
19:10:54 <jarolrod> Concept ack on cmake, the introduction of this build system doesn’t mean we have to remove autotools now
19:11:06 <sipa> There has been a lot of (constructive, I think) discussion on this on the PR itself.
19:11:16 <sipa> Especially the last few hours.
19:11:21 <fanquake> I disagree that a switch from Gitian to Guix is similar to what is being proposed here. Gitian -> Guix was basically internal to our project, autotools -> cmake breaks everything all infrastructure outside project.
19:11:39 <fanquake> *all infra outside our project
19:11:52 <jonatack> sorry for late addition to the 0.24 topic, it would be nice to get #25614 in for the release in order to resume making progress on the parent PR, the original pull was opened on june 2 and it now has many ACKs (a hopefully-final re-push coming in the next few hours after I finish verifying building each commit, logging changes take a long time to
19:11:52 <jonatack> build)
19:11:54 <gribble> https://github.com/bitcoin/bitcoin/issues/25614 | logging: add `-loglevel` configuration option and a `trace` log level by jonatack · Pull Request #25614 · bitcoin/bitcoin · GitHub
19:12:23 <jarolrod> fanquake: we don’t have to remove autotools now, and other infra can have time to adjust to cmake
19:12:29 <achow101> is it possible to have autotools call cmake internally?
19:12:51 <hebasto> achow101: yes, I guess
19:12:53 <achow101> to retain compatibliity with any downstream builders without having to actually maintain two build systems
19:13:02 <hebasto> Qt did so
19:13:11 <cfields> i also take issue with (and resent the implication) that an outside library forces our hand on our own infrastructure. I get that CMake is likely inevitible for us, but qt6 certinaly is not and imo that sets a terrible precedent.
19:13:15 <sipa> That seems hard, if cmake doesn't support in-tree builds?
19:13:48 <hebasto> cmake supports
19:13:54 <vasild> cmake does support in-tree builds
19:13:59 <hebasto> current implementation does not
19:14:00 <fanquake> jarolrod: I've mentioned on the PR that I'm not in favour of maintaining multiple build systems, at least certainly not over multiple releases.
19:14:05 <sipa> oh, i must have misread then
19:14:11 <jarolrod> cfields: i think hebasto was stating his personal motivation on working on this now
19:14:31 <hebasto> are in-tree builds so viable?
19:14:45 <achow101> does qt6 strictly require cmake for using it?
19:14:48 <cfields> jarolrod: he said that his motiviation stems from an inevitibility. I'm disagreeing with that.
19:14:50 <hebasto> * valuable
19:15:09 <hebasto> achow101: to get static builds -- yes
19:15:13 <laanwj> in-tree builds with cmake are extremely uncommon, everyene uses out-of-tree builds
19:15:22 <hebasto> ^ true
19:15:54 <sipa> I'm not convinced that in-tree builds are necessary to support, nor am I convinced that we necessarily need to make a compatibility layer that works autotools-like but invokes cmake. My point is that if we care about such compatibility, if it then doesn't support in-tree builds as autotools users expect, it is kind of pointless.
19:15:57 <vasild> yes, because it is so much straight-forward to just "rm -fr build"
19:16:13 <laanwj> vasild: right, for all intents and purposes they're superior
19:16:45 <sipa> If we make the choice to move to cmake, I think it's also fine to adopt some of the best practices and expectations that are common around cmake.
19:16:49 <cfields> agreed, the out-of-tree builds by default are a nice feature imo.
19:16:53 <laanwj> always use them for autotools builds too
19:17:11 <fanquake> In regards to 2. I think we need more feature parity before merging. i.e basics like a target for running the unit tests, generating installers etc
19:17:28 <hebasto> ^ agree
19:17:42 <fanquake> with the assumption that the rest would be filled in before the end of a release cycle.
19:18:38 <sipa> I'd say when we merge cmake, we should have (or have the strong expectation to do within the same release) guix builds working with it, as well as CI.
19:18:50 <fanquake> Yes, that would also be a requirement I think.
19:18:56 <jarolrod> ^^ that's reasonable
19:19:20 <vasild> hmm, I never managed to get autotools out-of-source builds work with and create proper compile_commands.json (created in a hackish way using bear(1)), so I use in-source-builds (uck!)... cmake can create compile_commands.json natively
19:19:26 <jarolrod> maybe reasonable is too loose of a word :)
19:19:39 <shiza> are you removing autotools?
19:19:53 <jarolrod> not in the proposed PR
19:20:03 <sipa> shiza: opinions appear divided on what the timeline for that would be
19:21:29 <shiza> have to remove? can't just let it rot?
19:21:45 <cfields> answered as framed? :)
19:21:59 <sipa> if it's not tested anymore, it should be removed
19:22:02 <sipa> if it's still tested, it can't be rotting
19:22:10 <fanquake> No. Because then there are very blurred expectations about what to fix or not, what feature parity to maintain. Things will break and degrade
19:22:25 <fanquake> It'll just be a prolonged migratory mess.
19:22:45 <fanquake> ^ in response to "let it rot"
19:23:18 <jarolrod> well if we write it off as such at the start, and people "dont care" maybe. But if we work on it, it wouldn't be a mess
19:24:17 <jarolrod> such as the example of the switch form gitian to guix
19:24:28 <laanwj> can't think of any reason to leave a 'rotting' build system, same reason not to leave unused code in, if you really need it you can always get it from git history
19:24:37 <shiza> Oh meeting in progress
19:24:40 <shiza> leaves in shame
19:25:56 <sipa> I personally believe shortening the transition period as much as possible is better, and we shouldn't merge before it's clear that a short transition is possible.
19:26:15 <jarolrod> i also think there's a lot of holes in the discussion here, not sure what to discuss on timeline or anything, maybe revisit again in another meeting as there's more work done and people have had more time to think about this?
19:26:46 <sipa> I think it was very useful that hebasto posted a list of supported/unsupported features in the PR currently.
19:27:00 <sipa> That gives a substance to discuss.
19:27:20 <hebasto> definitely, the common make targets must be implemented first
19:28:11 <sipa> vasild_: What's compile_commands.json?
19:28:36 <fanquake> sipa: what we use to run the clang-tidy checks and IWYU in the CI. Basically a .json file of the commands run by the compiler during compilation.
19:28:47 <cfields> ack, very helpful for llvm tooling like clang-tidy.
19:28:53 <vasild_> sipa: json db thah contains how each .cpp file is compiled - compiler + flags, is used for clang's semantic auto-completion
19:28:54 <fanquake> Currently we use a utility called bear to generate it, that intercepts the compiler
19:29:04 <sipa> ah, nice
19:29:38 <vasild_> sipa: I mean, it needs to compile the code to know better, compared to just a powerful grep + whatnot
19:29:43 <laanwj> yes it's a common standard for all kinds of project wide static analysis tooling, apparently
19:30:14 <cfields> has just been adding make convenience targets *ducks*
19:30:59 <cfields> joking ofc, automatic json output would be very nice :)
19:31:00 <laanwj> that works too
19:31:34 <shiza> not sure about bcha, but bchn builds using cmake
19:32:24 <vasild_> cmake has -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON
19:32:35 <vasild_> natively
19:32:48 <laanwj> yes!
19:33:10 <laanwj> i think we've discussed everything for this topic let's move to next one
19:33:13 <vasild_> (which works regardless of whether in-tree or out-of-tree build)
19:33:23 <hebasto> thank you all
19:33:36 <laanwj> #topic vasild for a new maintainer with a focus on P2P/networking
19:33:36 <core-meetingbot> topic: vasild for a new maintainer with a focus on P2P/networking
19:33:51 <vasild_> Two maintainers stepped down recently (sipa and laanwj) and there is no dedicated maintainer for P2P/networking. So I step in coz I think I can help the project in that way. That's it.
19:34:35 <laanwj> i think it would make some sense, you've been the most active in P2P development for quite a while
19:34:53 <jarolrod> concept ack, i think vasild_ is very qualified for such a role. And has contributed important changes to the p2p code. He also has done extensive reviews, and catching issues others don't catch
19:35:04 <michaelfolkson> +1
19:36:18 <vasild> was disconnected
19:36:32 <shiza> perfect timing
19:36:47 <hebasto> concept ack
19:37:03 <achow101> ack
19:37:07 <lightlike> ack vasild
19:37:09 <jonatack> a thought: the past few years vasild, laanwj, and myself have been working on or reviewing a large-ish chunk of net code that few others have been. i believe sipa knows the code well, too, along with (maybe) a couple others. laanwj has been merging these changes. so it makes sense to me that one of these would maintain.
19:37:19 <fanquake> re p2p/networking. Are you talking peer interaction / net processing, or lower level networking / sockets. Or both?
19:38:02 <vasild> Both
19:39:05 <vasild> but I think boundaries are fuzzy
19:40:35 <michaelfolkson> If there's no opposition from people here have vasild open a PR adding his trusted keys and see if there is any further discussion there?
19:40:46 <cfields> there were lots of concerns around process last time. have those somehow dried up, or are those people simply not here today?
19:41:21 <laanwj> there shouldn't be decisions made in the meeting anyhow
19:42:24 <michaelfolkson> It is a bit strange. There were concerns about process for installing a maintainer and then PRs got opened about what should be expected from maintainers once installed
19:42:51 <michaelfolkson> They seem orthogonal to me
19:43:20 <laanwj> yeah...
19:44:03 <michaelfolkson> But there was discussion on the trusted keys PR for Gloria which I think was mostly productive. So doing that again for vasild seems like the way to go
19:44:41 <michaelfolkson> (if there is anything to discuss)
19:44:54 <cfields> agreed. i'm sure they'll speak up again there.
19:45:12 <vasild> So I guess I open PR and see what happens there?
19:45:32 <jarolrod> i hope we don't move towards too much bureaucracy with how the project moves/works
19:45:47 <jarolrod> ^ in relation to documenting the exact role of maintainers
19:47:49 <laanwj> sgtm
19:48:08 <laanwj> any other topics?
19:48:10 <jonatack> i have some ideas about maintainership standards that would be in the spirit of carrying on laanwj's style in a possibly more decentralized way, but that's for another day
19:48:17 <jonatack> ack vasild for me in any case
19:48:28 <laanwj> jonatack: +1
19:49:09 <bitcoin-git> [bitcoin] furszy opened pull request #25869: wallet: remove UNKNOWN type from OUTPUT_TYPES array (master...2022_fix_output_type_fuzz) https://github.com/bitcoin/bitcoin/pull/25869
19:49:21 <laanwj> if nothing else, that concludes the meeting for today
19:49:25 <laanwj> #endmeeting