<laanwj>
welcome to the weekly bitcoin-core-dev meeting
<ajonas>
Hi
<cfields>
hi
<vasild>
hi
<fanquake>
hi
<michaelfolkson>
hi
<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
<sipa>
hi
<laanwj>
might also make sense to discuss for the 24.0 milestone (instead of high priority for review)
<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
<hebasto>
The current benefits are outlined in the PR description.
<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.
<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.
<hebasto>
A comment in PR mentioned "bells and whistles".
<hebasto>
Here is my personal motivation disclosure.
<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.
<hebasto>
Here are the suggested questions for discussion now
<hebasto>
1. Are we open for a CMake-based build system (CM) in general?
<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?
<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?
<hebasto>
that is it, let's discuss
<jarolrod>
Concept ack on cmake, the introduction of this build system doesn’t mean we have to remove autotools now
<sipa>
There has been a lot of (constructive, I think) discussion on this on the PR itself.
<sipa>
Especially the last few hours.
<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.
<fanquake>
*all infra outside our project
<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
<jonatack>
build)
<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
<jarolrod>
fanquake: we don’t have to remove autotools now, and other infra can have time to adjust to cmake
<achow101>
is it possible to have autotools call cmake internally?
<hebasto>
achow101: yes, I guess
<achow101>
to retain compatibliity with any downstream builders without having to actually maintain two build systems
<hebasto>
Qt did so
<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.
<sipa>
That seems hard, if cmake doesn't support in-tree builds?
<hebasto>
cmake supports
<vasild>
cmake does support in-tree builds
<hebasto>
current implementation does not
<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.
<sipa>
oh, i must have misread then
<jarolrod>
cfields: i think hebasto was stating his personal motivation on working on this now
<hebasto>
are in-tree builds so viable?
<achow101>
does qt6 strictly require cmake for using it?
<cfields>
jarolrod: he said that his motiviation stems from an inevitibility. I'm disagreeing with that.
<hebasto>
* valuable
<hebasto>
achow101: to get static builds -- yes
<laanwj>
in-tree builds with cmake are extremely uncommon, everyene uses out-of-tree builds
<hebasto>
^ true
Talkless has quit [Quit: Konversation terminated!]
<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.
<vasild>
yes, because it is so much straight-forward to just "rm -fr build"
<laanwj>
vasild: right, for all intents and purposes they're superior
<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.
<cfields>
agreed, the out-of-tree builds by default are a nice feature imo.
<laanwj>
always use them for autotools builds too
<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
<hebasto>
^ agree
<fanquake>
with the assumption that the rest would be filled in before the end of a release cycle.
<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.
<fanquake>
Yes, that would also be a requirement I think.
<jarolrod>
^^ that's reasonable
<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
<jarolrod>
maybe reasonable is too loose of a word :)
<shiza>
are you removing autotools?
<jarolrod>
not in the proposed PR
<sipa>
shiza: opinions appear divided on what the timeline for that would be
<shiza>
have to remove? can't just let it rot?
<cfields>
answered as framed? :)
zyu has quit [Quit: Connection closed]
<sipa>
if it's not tested anymore, it should be removed
<sipa>
if it's still tested, it can't be rotting
<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
<fanquake>
It'll just be a prolonged migratory mess.
<fanquake>
^ in response to "let it rot"
<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
<jarolrod>
such as the example of the switch form gitian to guix
<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
<shiza>
Oh meeting in progress
* shiza
leaves in shame
<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.
<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?
<sipa>
I think it was very useful that hebasto posted a list of supported/unsupported features in the PR currently.
<sipa>
That gives a substance to discuss.
<hebasto>
definitely, the common make targets must be implemented first
vasild_ has joined #bitcoin-core-dev
<sipa>
vasild_: What's compile_commands.json?
<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.
<cfields>
ack, very helpful for llvm tooling like clang-tidy.
<vasild_>
sipa: json db thah contains how each .cpp file is compiled - compiler + flags, is used for clang's semantic auto-completion
<fanquake>
Currently we use a utility called bear to generate it, that intercepts the compiler
<sipa>
ah, nice
<vasild_>
sipa: I mean, it needs to compile the code to know better, compared to just a powerful grep + whatnot
<laanwj>
yes it's a common standard for all kinds of project wide static analysis tooling, apparently
* cfields
has just been adding make convenience targets *ducks*
vasild has quit [Ping timeout: 268 seconds]
<cfields>
joking ofc, automatic json output would be very nice :)
<laanwj>
that works too
<shiza>
not sure about bcha, but bchn builds using cmake
<vasild_>
cmake has -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON
<vasild_>
natively
<laanwj>
yes!
<laanwj>
i think we've discussed everything for this topic let's move to next one
<vasild_>
(which works regardless of whether in-tree or out-of-tree build)
<hebasto>
thank you all
<laanwj>
#topic vasild for a new maintainer with a focus on P2P/networking
<core-meetingbot>
topic: vasild for a new maintainer with a focus on P2P/networking
<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.
vasild_ has quit [Remote host closed the connection]
<laanwj>
i think it would make some sense, you've been the most active in P2P development for quite a while
<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
<michaelfolkson>
+1
vasild has joined #bitcoin-core-dev
* vasild
was disconnected
<shiza>
perfect timing
<hebasto>
concept ack
<achow101>
ack
<lightlike>
ack vasild
<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.
<fanquake>
re p2p/networking. Are you talking peer interaction / net processing, or lower level networking / sockets. Or both?
<vasild>
Both
<vasild>
but I think boundaries are fuzzy
<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?
<cfields>
there were lots of concerns around process last time. have those somehow dried up, or are those people simply not here today?
<laanwj>
there shouldn't be decisions made in the meeting anyhow
<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
<michaelfolkson>
They seem orthogonal to me
<laanwj>
yeah...
Guest63 has joined #bitcoin-core-dev
<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
<michaelfolkson>
(if there is anything to discuss)
<cfields>
agreed. i'm sure they'll speak up again there.
<vasild>
So I guess I open PR and see what happens there?
<jarolrod>
i hope we don't move towards too much bureaucracy with how the project moves/works
<jarolrod>
^ in relation to documenting the exact role of maintainers
<laanwj>
sgtm
<laanwj>
any other topics?
<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
<jonatack>
ack vasild for me in any case
<laanwj>
jonatack: +1
<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
<laanwj>
if nothing else, that concludes the meeting for today
<jonatack>
(the "couple others" i was referring to above are dongcarl and cfields, but i'm not sure) o/
___nick___ has quit [Ping timeout: 268 seconds]
_apex2_ has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 248 seconds]
jonatack has quit [Ping timeout: 256 seconds]
_andrewtoth_ has quit [Quit: Leaving]
_andrewtoth_ has joined #bitcoin-core-dev
<jeremyrubin>
> there were lots of concerns around process last time. have those somehow dried up, or are those people simply not here today?
<jeremyrubin>
simply not present; i had a real-world obligation today
<jeremyrubin>
w.r.t. the docs being put forth, i'm not sure what document michaelfolkson is looking at, but the docs i wrote up were trying to handle the elements that were being discussed, and not orthogonal stuff. majority of the docs are around process for adding maintainers
<jeremyrubin>
the point of "what maintainers do once installed" is that we had offered up people as scoped maintainers, as vasild is being proposed to be, and then it was clear that was not actually a defined thing, so the notion of a scoped maintainer is basically "undefined behavior"
<jeremyrubin>
as such, a guide trying to document what an installation process is had to also do the lift of defining what the role people are being installed into is
<jeremyrubin>
people balked at a new document containing both descriptive of status quo and new process, so those have been split up with #25839 being just a minimal description of what is done today
<jeremyrubin>
i am personally strongly opposed to adding _any maintainer_ at this time, although i have minimal qualms with vasild, i dont think we are setting our project up for success by adding maintainers in the manner we are doing it presently
_andrewtoth_ has quit [Remote host closed the connection]
<michaelfolkson>
jeremyrubin: So you would like to consider jonatack as a possible alternative to vasild although you have minimal qualms with vasild. Ok I guess question to jonatack. Would you like to put your name forward as a possible alternative to vasild?
<michaelfolkson>
jonatack has ACKed this
<michaelfolkson>
If he had misgivings and thought he would be better for this role I doubt he would have ACKed it
<michaelfolkson>
Ok so the 2 man band in the issue are fine with vasild but would like to propose jonatack as an additional maintainer after that
<michaelfolkson>
So we're still in the position where vasild should open his trusted keys PR for further discussion there. And the two man band can propose jonatack for a maintainer role in the meeting next week where that can be considered/discussed
<michaelfolkson>
(I actually agree that jonatack would be an excellent candidate for maintainer also but that wasn't the subject of today's meeting)
sipsorcery has quit [Ping timeout: 244 seconds]
Guest63 has quit [Quit: Client closed]
evanlinj1 has quit [Remote host closed the connection]
evanlinj1 has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
<achow101>
I do not think we should discuss any further on whether a particular person is a good fit for maintainer before they have stated that they are willing to be a maintainer
<achow101>
as otherwise we may put undue pressure (in either direction) on that decision
<achow101>
remember that maintainership is a position people volunteer for, not be appointed to
Guest27 has joined #bitcoin-core-dev
Guest27 has quit [Client Quit]
<michaelfolkson>
achow101: Agreed
sipsorcery has joined #bitcoin-core-dev
_apex2_ has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 248 seconds]
kouloumos has quit [Quit: Connection closed for inactivity]