16:00:39 <achow101> #startmeeting 
16:00:39 <corebot> achow101: Meeting started at 2025-01-30T16:00+0000
16:00:40 <corebot> achow101: Current chairs: achow101
16:00:41 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:42 <instagibbs> hallo
16:00:43 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:44 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:47 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
16:00:48 <jonatack> achow101: not at this time, ty
16:00:50 <jonatack> hi
16:00:53 <TheCharlatan> hi
16:00:57 <kevkevin> hi
16:01:02 <sr_gi[m]> Hi
16:01:03 <hebasto> hi
16:01:09 <ajonas> hi
16:01:09 <darosior> hi
16:01:09 <achow101> There are 2 preproposed topics this week. Any last minute ones to add?
16:01:13 <brunoerg> hi
16:01:16 <kevkevin> #here 
16:01:18 <sipa> hi
16:01:23 <pinheadmz> yo
16:01:26 <darosior> #here \" DROP TABLE actions
16:01:28 <Sjors[m]> hi
16:01:32 <cfields> hi
16:01:37 <hodlinator> hi
16:01:40 <achow101> darosior: rude
16:01:56 <lightlike> hi
16:01:59 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
16:02:35 <fjahr> hi
16:03:07 <sr_gi[m]> Following from last week’s meeting, I mentioned that after running a wide range experiment with different combinations of parameters for how to select fanout peers, a less static approach was proposed by @murch: instead of having a fixed fanout rate (selecting some inbounds and outbounds), we could have a variable rate based on how the peer has received the transaction
16:03:11 <abubakarsadiq> hi
16:03:13 <furszy> hi
16:04:00 <sr_gi[m]> This tries to guess how propagated the transaction is to use more fanout or more reconciliation to keep propagating it
16:05:00 <sr_gi[m]> It is something we previously tried by checking how many peers may have announced a transaction by the time we needed to pick to how many peers to fanout to, but that approach, while promising, didn't seem to work too well
16:05:21 <sr_gi[m]> Long story short, @murch suggestion yield really interesting results
16:05:56 <sr_gi[m]> Reducing the transaction propagation latency by a significant bit while not affecting the bandwidth too much
16:06:38 <sr_gi[m]> A full explanation of the approach, experiment, results and conclusions can be found here, for those interested: https://srgi.notion.site/Define-the-transaction-fanout-rate-based-on-whether-the-node-has-received-the-transaction-via-fanout-18a7b3fef9778097a922fac307125de2#18a7b3fef97780b59ebbfede420d76d7
16:08:03 <jonatack> nice
16:08:24 <sr_gi[m]> Next is to decide if modifying the poisson timers for erlay, in order to achieve better latency, is acceptable, and to what extend, or if we could find an alternative solution that may be less intrusive
16:08:39 <sr_gi[m]> That's it on my end
16:09:02 <achow101> #topic Kernel WG Update (TheCharlatan)
16:09:14 <TheCharlatan> I don't have much to share this week, but stickies-v published a python wheel https://www.piwheels.org/project/py-bitcoinkernel/ for the pip package https://pypi.org/project/py-bitcoinkernel/ for wrapping the proposed kernel API.
16:09:35 <TheCharlatan> Seems like some people already are using them for gathering transaction and block data.
16:10:01 <abubakarsadiq> nice, this is more convenient to use
16:10:24 <TheCharlatan> Other than that I am looking for review on #31382.
16:10:34 <sipa> #31382 
16:10:36 <corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
16:10:49 <TheCharlatan> ty :)
16:12:10 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:12:44 <sdaftuar> oh hi
16:13:11 <sdaftuar> my update is that i was able to rebase my big PR on sipa's work, so #28676 can be looked at to get an idea of how sipa's code will be used
16:13:15 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
16:13:17 <Murch[m]> Hi  (think I wasn’t authed earlier)
16:13:38 <sdaftuar> i still need to do more cleanups on my branch, so leaving it in draft (as sipa's PRs still need review anyway)
16:13:57 <sdaftuar> that's it from me
16:14:08 <achow101> #topic Stratum v2 WG Update (sjors)
16:14:13 <instagibbs> I've been taking a peek, thanks sdaftuar
16:14:19 <glozow> thanks sdaftuar!
16:14:37 <Sjors[m]> There's a Matrix chat for the work group, that's mostly quiet
16:14:52 <Sjors[m]> But you can dm your Matrix username to be added there. Or we can try another platofmr.
16:15:04 <Sjors[m]> #31756 is a good followup of last weeks discussion
16:15:05 <corebot> https://github.com/bitcoin/bitcoin/issues/31756 | RFC: multiprocess binaries in 29.0 · Issue #31756 · bitcoin/bitcoin · GitHub
16:15:45 <Sjors[m]> I'm personally not assuming we'll meet the v29 release, but it would be good to continue the discussion there so we're on the same page for e.g. v30
16:16:07 <Sjors[m]> Next on peoples review list, suggested: #31283
16:16:09 <corebot> https://github.com/bitcoin/bitcoin/issues/31283 | Add waitNext() to BlockTemplate interface by Sjors · Pull Request #31283 · bitcoin/bitcoin · GitHub
16:16:27 <Sjors[m]> That's the last bit of the interface.
16:16:46 <Sjors[m]> The interface and getting multiprocess in A release is pretty much all that's needed.
16:18:32 <achow101> #topic MuSig2 WG Update (achow101)
16:18:43 <abubakarsadiq> nice I will take a look! @sjors[m] I see you rebase your branch on #31384, can we have the 29.0 milestone on it?
16:19:08 <achow101> No update really, been a bit incapacitated this week. Still planning to write some psbt test vectors soon(tm)
16:19:28 <achow101> The next pr to review is #31243
16:19:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
16:19:34 <Sjors[m]> abubakarsadiq: that milestone only makes sense if we still aim for v29
16:19:44 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
16:20:17 <achow101> #31241 was merged. The next pr is #31495 which looks like there is some review I need to address.
16:20:20 <corebot> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
16:20:25 <corebot> achow101: Error: That URL raised <Connection timed out.>
16:20:37 <achow101> Other than that, not much else
16:20:46 <sipa> #31495 
16:20:49 <corebot> https://github.com/bitcoin/bitcoin/issues/31495 | wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases by achow101 · Pull Request #31495 · bitcoin/bitcoin · GitHub
16:21:07 <abubakarsadiq> Milestone for
16:21:08 <abubakarsadiq> #31384 
16:21:13 <corebot> https://github.com/bitcoin/bitcoin/issues/31384 | mining: bugfix: Fix duplicate coinbase tx weight reservation by ismaelsadeeq · Pull Request #31384 · bitcoin/bitcoin · GitHub
16:21:24 <achow101> #topic orphan resolution WG Update (glozow)
16:21:36 <glozow> I'm working on my per-peer orphanage branch, which is maybe 80% of the way there.
16:21:46 <glozow> (80%TM)
16:22:03 <sipa> the second 80% might take less than the first 80%
16:22:19 <glozow> I'm trying to get #31666 merged soon as it's based on that. A little bit of active discussion left on the the AddChildrenToWorkset assignment, happy to punt that or defend it
16:22:21 <corebot> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
16:23:28 <glozow> sipa: haha. I'm going a little bit back and forth on the count limits thing, might just end up incorporating the struct memory usage after benching it
16:23:38 <glozow> anyway I hope to have my PR up soon
16:24:11 <sipa> glozow: happy to discuss more
16:24:21 <glozow> I might actually trim things like "give outbounds more space than inbounds" to make it smaller / more realistic for v29
16:24:36 <glozow> sipa: thanks
16:24:44 <sipa> as in 400 kWU for everyone?
16:24:47 <glozow> yes
16:25:18 <sipa> do we have a way of gathering data whether or not that would affect any actual tx relay right now?
16:26:07 <instagibbs> I asked timo but he's busy this week, so if anyone has high quality node data
16:26:16 <glozow> hmmm, is the best way to analyze that to measure how many bytes peers use right now?
16:26:16 <instagibbs> (read: not randomly shutting machines off like mine)
16:26:27 <sipa> glozow: i think so
16:26:58 <glozow> my byte accounting code seems correct(TM), we could start running that now
16:27:32 <glozow> well this can also be inferred from the `getorphantxs` RPC results
16:27:34 <instagibbs> beneficial to make sure logging is decent for 29.0. whatever happens?
16:27:40 <instagibbs> I expect it to be very bursty
16:28:07 <glozow> yeah i expect it to be very high at first, and then taper off
16:28:24 <glozow> idea: orphanage can borrow some space from mempool when it's not full?
16:28:58 <glozow> (maybe we should continue this later? meeting can go on?)
16:29:05 <instagibbs> ✅
16:29:06 <sipa> let's discuss after
16:29:10 <achow101> #topic mutation testing (brunoerg)
16:29:27 <brunoerg> Hi, just a quick announcement that I’m performing mutation testing and publishing the reports at bitcoincore.space. I do it based on master branch once a week (every Monday, I guess) and then I update the website with the results
16:29:34 <brunoerg> I started to do it on more important/critical part of the codebase (pow, tx_check, script interpreter, etc) but I intend to expand it soon. Any suggestions for function/code file to include next on it, let me know.
16:30:02 <brunoerg> that's it
16:30:21 <sipa> you run that website?
16:30:25 <brunoerg> yes
16:30:26 <achow101> how are you generating mutations? by hand?
16:30:40 <brunoerg> no, using my own tool
16:30:56 <brunoerg> https://github.com/brunoerg/mutation-core
16:31:06 <darosior> Nice.
16:31:08 <sipa> nice site
16:31:11 <achow101> neat
16:32:10 <achow101> #topic What should be the mid to long term goals of the project? (darosior)
16:32:22 <achow101> this sounds like a question for coredev
16:32:25 <darosior> Hi, see https://antoinep.com/posts/core_project_direction for the longer version but here is the TL;DR. With limited resources there is an upper bound on the amount of stuff the project can maintain. We can pay in either a limited project scope or a reduced overall software quality but we can't have it for free.
16:32:25 <darosior> Resources are also spread inequally. It's very hard to onboard and make meaningful impact in important areas. With key people leaving or reducing their involvement we've at best had constant resources despite an increasing number of contributors. Despite this, the scope of the project has been constantly increasing.
16:32:25 <darosior> Bitcoin Core cannot be the "everything Bitcoin app" without also diluting priorities. Not doing anything about it is making this choice by default. Finally, defining a scope is not only about pruning stuff. It can also help us shift focus toward things we would see as in-scope but not making enough progress.
16:32:25 <darosior> For the purpose of this meeting i'm interested in:
16:32:25 <darosior> 1. do people make the same observation / agree with the problem statement in the first place?
16:32:25 <darosior> 2. do people agree that defining a scope / long term vision for the project is an appropriate solution?
16:32:25 <darosior> 3. hearing about others' thoughts about this issue.
16:32:26 <darosior> Note i obviously do not expect to find a solution in a single IRC meeting. But i think it's good to kick off the discussion here, and continue it at Coredev.
16:32:43 <darosior> achow101: yes but i figured it could be helpful to start the discussion here
16:35:09 <Sjors[m]> In what areas has the scope been increasing in e.g. the last 5 years though?
16:35:12 <glozow> I agree it's hard to do the topic justice in this meeting. appreciate that you're posting this here ahead of coredev
16:35:25 <Sjors[m]> There's been 0 new GUI features, IIRC only a handful of new RPC calls.
16:35:33 <sipa> i have many thoughts about this, but i'll try to organize them before coredev
16:36:15 <Sjors[m]> There's certainly a desire to increase scope in various places, but this often goes nowhere because - as you point out - we're already quite stretched.
16:36:57 <achow101> have a few thoughts on this as well, will also try to organize them before coredev
16:37:18 <glozow> I disagree the scope hasn't increased - "a handful of RPCs" in the last 5 years is around 50. the security requirements certainly have increased
16:37:35 <darosior> Sjors[m]: i don't want to make this a discussion about "should we drop  the GUI", although removing it from the main project could definitely be part of defining a scope.
16:37:47 <abubakarsadiq> @sjors[m] this might be an indicator that the gui is not getting much improvements
16:38:58 <TheCharlatan> darosior beyond the three questions you are asking is there further homework we could be doing to be better prepared when discussing in person?
16:39:12 <darosior> Sjors[m]: it's pretty obvious the project has been getting bigger in any metric one can think of, and you static you are not seeing that is an illustration of the issue we are facing here.
16:39:22 <darosior> s/static/stating
16:39:32 <sipa> I think RPCs are a bad metric for measuring scope creep, dilution, or lakc of focus (all of which are real problems we suffer from). The actual maintenance cost for most RPCs, on a per-RPC basis, is small; the cost is in the code subsystem behind it.
16:40:18 <glozow> Right, should we be preparing our thoughts on what we think the goals should be + to what extent we think we should/can be planning?
16:40:44 <darosior> TheCharlatan: thanks for asking, yes i think it would be nice if we all thought about "What should be the scope of the project", "What should be Bitcoin Core's mission", so we can get inputs from as many people as possible for this discussion
16:40:44 <glozow> er yes, agree number of RPCs is not that meaningful, I just had a nitpick moment
16:40:47 <jonatack> i've had concerns for some time now about the collectivist "we" approach, particularly in a project where decentralization is the fundamental value
16:40:56 <fanquake> Sjors: I have a hard time agreeing with no scope increase. If we haven't increased our scope at all, what are the hundreds of thousands of new lines of code for
16:41:27 <Sjors[m]> I'm using a fairly narrow defination of scope, things like features and functionality.
16:41:46 <achow101> perhaps the first exercise is to define "scope"
16:41:49 <Sjors[m]> But if you mean "scope" as in things people work on, then there's more, that would include refactors.
16:41:50 <darosior> jonatack: yeah i agree with that, but also individual actions have negative externalities on the project at large and we need collective actions to work against them.
16:41:58 <sipa> I also disagree that an expanding scope is *necessarily* a problem. I believe it's a natural consequence of shifting interesting in a software being developed, even if no prioritization/focus issues existed.
16:42:02 <lightlike> what would help is concrete example of stuff that has been merged in the past but wouldn't / shouldn't have been merged with a "scope".
16:42:27 <sipa> lightlike: yes, making this concrete helps for the purpose of discussion.
16:43:00 <fanquake> lightlike: I think it's less things wouldn't have been merged, and more we need to face the reality that we can't keep adding new stuff with continued brain drain/flat-if-not-declining engineering capacity
16:43:06 <darosior> jonatack: there is a balance to strike between "everyone work on their stuff and the project decays" and "some people decide what everybody else should be spending their time on"
16:43:17 <sipa> darosior: agreed
16:43:56 <darosior> achow101: yes i agree, when thinking about this i found that defining scope would be the first step to then layout a set of priorities and then take action upon those priorities
16:44:02 <fanquake> we are already shipping things that you could consider unmaintained. i.e a GUI that doesn't work out of the box on one of the platforms we support (macOS)
16:44:23 <sipa> fanquake: yes, but i think the correct thing to look at is concrete examples that cause us maintenance cost. I believe there can exist maintained, fully functional, but not being-developed, features in the codebase, which do not cause the project a high cost.
16:44:51 <sipa> While there are other examples of things that exist in a half-finished state, which interact with lots of other things, and possible detract review power from other, more impactful things.
16:45:16 <sipa> So I think it's important to keep this concrete, and not just look at the codebase and "look, more RPCs, more lines of code, bad!".
16:45:25 <darosior> lightlike: yes i can try to compile a list of things that should have seen more focus and others that should have seen less before Coredev, but this is necessarily going to be stepping on eggs
16:45:38 <fanquake> sipa: possibly, but that doesn't solve the issue that the poeple that wrote that code are dissapearing, and the new people don't understand/can't maintain it if needed
16:45:58 <sipa> fanquake: that's fair, but i don't think this applies to the vast majority of the codebase
16:46:12 <fanquake> sure, but it applies to the most important parts
16:46:30 <glozow> I think we could focus more on how we spend resources + existing efforts to increase resources. That could potentially be a more productive conversation, though there are no easy solutions
16:46:32 <sipa> so, i'd like to encourage people to come up with specific examples
16:47:11 <ajonas> Coredev or here, I think the format to have this discussion is a challenge. Venting is healthy but there have been attempts to address meta-level project improvements in the past and it's hard to get to meat of it or come to any concrete steps going forward. It'd be great if there were ideas to discuss this in something other than a 1-to-N way where most people stay silent.
16:47:12 <Sjors[m]> darosior: bring eggs :-) it's good to have examples as a starting point
16:48:18 <sipa> We should discuss this on a meta-level too of course, but there is only so much talk can accomplish. Actually talking about specific projects can help people focus on them (for review, or for discussion on deprecation/removal/moving out alike!), and ultimately that is the only thing that will change things.
16:48:29 <jonatack> darosior: when in doubt, I think the balance to strike is in favor of decentralizad, ad hoc, less process
16:48:47 <laanwj> is the gui broken on macos?
16:49:10 <darosior> jonatack: this is a bunch of undefined terms that are not helpful to take concrete actions
16:49:14 <fanquake> laanwj: yes, it is unsable for any non-technical user, due to lack of notarization/codesigning issues
16:49:27 <achow101> fanquake: there's literally a pr for that
16:49:36 <fanquake> yes, with literally 0 review
16:49:41 <darosior> achow101: that has seen no review
16:49:44 <laanwj> fanquake oh, that, i was afraid it'd be another qt issue but that seems kind of meta
16:49:52 <darosior> ie, nobody cares enough
16:49:57 <achow101> fanquake: you're one of 2 people with the macos code signing key, you're the reviewer
16:50:08 <darosior> haha
16:50:09 <fanquake> we can't claim that we need to have feature x, but at the same time nobody is reivewing the changes needed to ship feature x
16:50:28 <fanquake> achow101: I don't see how who has the signing keys is relevant here
16:50:50 <sipa> fanquake: i think it's important to distinguish between "we should have feature X", and "hey guys we talked about feature X, it seems people want it, can it be reviewed please?".
16:51:16 <darosior> Alright, i guess i've done my advertisement. Please everyone do a bit of thinking about the issue before Coredev so we all participate in this discussion and finally are able to take actions. We have been talking about this for years now.
16:51:22 <fanquake> sipa: sure. I guess here I am talking about things we already have, which are just degrading
16:51:36 <sipa> fanquake: i'd really like you to be specific :)
16:51:42 <fanquake> sipa: the macOS gui
16:51:46 <Sjors[m]> I do occasionally review those macOS signing key PRs, but they're often impossible to test without signatures.
16:51:48 <fanquake> which doesn't work
16:52:02 <Sjors[m]> IIRC I asked for those a while back, but can check again.
16:52:13 <achow101> fanquake: a code signature from a code signer makes reviewing code signing changes easier/possible
16:52:36 <sipa> ok, who here uses macOs?
16:52:38 <fanquake> achow101: sure, if someone pings me for one in that PR I can provide, as can the other signer
16:52:46 <Sjors[m]> And I use the macOS GUI all the time
16:52:52 <laanwj> the only mac is have is old and support for its version of macos was dropped so i can't help in that regard, at least not with testing
16:52:55 <sipa> achow101: what's the PR?
16:53:00 <achow101> #31407 
16:53:01 <jonatack> I have a recent mac
16:53:01 <corebot> https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
16:53:40 <darosior> Let's not derail the discussion into specifics
16:54:07 <Sjors[m]> And I know people run into lack of codesigning for the daemon too, see #29749.
16:54:20 <laanwj> it's just that discussion about reducing scope always goes into "drop the gui" and "drop the wallet" which happen to be the parts i find very importnat
16:54:34 <achow101> laanwj: indeed
16:55:04 <Sjors[m]> Indeed, and the wallet is also a useful  reference for other projects. See e.g. recent revival of PSBTv2 review.
16:55:09 <jonatack> Regarding the specific case of the GUI, getting funding for working on it has been a non-starter for years, perhaps somewha partially  related to moving out of the bitcoin core repo
16:55:17 <jonatack> laanwj: achow101: agree
16:55:26 <glozow> Ok so I think the meat here is "we seem to have lots of people, but people are not spending their energy on the right things. There are parts of the codebase that deserve significantly more/less attention than they're getting now. That can be dangerous for particularly important areas." I think we should come prepared to talk about what those specific areas are *with a specific focus on areas that require more attention, not less*. And think
16:55:26 <glozow> about why we personally don't work on certain things. Perhaps people naturally haven't learned much about an area. Obviously we have limited time. Maybe people are not incentivized/encouraged to do so (I don't just mean economically but that is part of it).
16:55:28 <darosior> jonatack: to be more concrete as to your concern which i would interpret as keeping enough "emergent process" in the project, i think this is desirable and not contradictory with defining a scope. Also, we can only take collective action about the scope of the project if there is rough consensus about said scope. If there is not, i don't think it
16:55:28 <darosior> will be possible to take action. I also think it would be a pretty bad outcome for the project.
16:55:54 <laanwj> re the gui, one reason for me losing the joy of working on it were these kind of discussions, it's always on the chopping block
16:56:36 <laanwj> has been since 2012 or so
16:57:09 <Sjors[m]> laanwj: it also just really hard to work with qt5. I'm hoping either QML + QT6 or multiprocess and external GUI will get things moving again eventually.
16:57:56 <hebasto> further gui development requires expanding dependencies. it’s another concern
16:58:08 <laanwj> in any case, i agree with keeping limit on scope creep in general, that's also what i've always tried, not every random RPC or GUI feature anyone asks for needs to be added, but i don't think that's the case either
16:58:56 <sipa> laanwj: agreed, it's not like we willy nilly take on extra features; "seems too tangential, can be done elsewhere" has long been a reason not to take things
16:58:58 <darosior> Alright, thanks everyone for chiming in. I'll try and compile more thoughts and data/examples about this issue.
16:59:00 <laanwj> hebasto: yeah, i tried limiting the build-time dependencies with my qtsowrap work last year, but there was almost no attention for it
16:59:06 <sipa> laanwj: :(
16:59:24 <sipa> i really liked that idea, but i also don't use the GUI
16:59:25 <lightlike> glozow: there is no real guidance for newer contributors as to which areas of the codebase would need more attention. maybe a good thing would be if some experienced contributors would just publish a list of areas that they think could  need more attention.
16:59:54 <jonatack> laanwj: I empathize
17:00:03 <laanwj> well it has to be updated for qt6 anyhow, that should go first
17:00:08 <sipa> laanwj: another idea i've seen more recently is the possibility with multiprocess of having a few-dependency (maybe statically built) core, and having a gui binary connect to it with more dependencies
17:00:21 <laanwj> but if we yet again go "oh maybe we should drop the gui" i find it hard to invest time in it
17:00:39 <laanwj> sipa: that would make sense
17:00:46 <jonatack> lightlike: yes. in general, I like the idea of contributors expressing these things in personal blog posts (rather than, say, in core dev documentation or processes)
17:00:48 <sipa> so that everyone still uses the same release core binary, focusing testing/review, but if you want to use the gui, you take on the (inevitable) cost of having more dependencies too
17:01:07 <fanquake> statically built core is certainly already possible, it's just somewhat of a mess to integrate without somewhat overhauling how we build releases, as we'll likely need to split into separete non-gui and gui builds
17:01:17 <achow101> I believe we're getting a bit off topic and into the weeds, so I'll end the meeting here. Feel free to continue discussing.
17:01:20 <achow101> #endmeeting