19:00:39 <wumpus> #startmeeting
19:00:39 <lightningbot> Meeting started Thu May 28 19:00:39 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:39 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:47 <achow101> hi
19:00:48 <sipa> hi
19:00:48 <fjahr> hi
19:00:50 <provoostenator> hi
19:00:55 <jnewbery> hi
19:01:01 <instagibbs> hi
19:01:06 <amiti> hi
19:01:07 <wumpus> #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:09 <harding> hi
19:01:09 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:01:17 <promag> hi
19:01:29 <jamesob> Hi
19:01:31 <dongcarl> hi
19:01:45 <troygiorshev> hi
19:01:45 <ariard> hi
19:01:46 <aj> hi
19:01:47 <wumpus> two proposed topics (by MarcoFalke): 0.20.0-final, separate repo for the gui
19:02:08 <MarcoFalke> hi, anyone heard or seen of issues with 0.20.0?
19:02:22 <kanzure> hi
19:02:23 <wumpus> none!
19:02:26 <sipa> yes, it's not released yet
19:02:32 <MarcoFalke> *rc2
19:02:38 <sipa> ;)
19:02:46 <MarcoFalke> ah
19:03:06 <jonasschnelli> hi
19:03:19 <provoostenator> I'm using rc2 on a Linux and macOS machine, so far so good.
19:03:22 <wumpus> if not, it's probably time to do the release soon
19:03:53 <MarcoFalke> ack
19:04:32 <wumpus> #topic High priority for review
19:04:50 <fjahr> #18000 can be removed from chasing concept ACK
19:04:52 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  currently 5 blockers, 1 bugfix, 4 chasing concept ACK
19:04:53 <gribble> https://github.com/bitcoin/bitcoin/issues/18000 | [WIP] Index for UTXO Set Statistics by fjahr · Pull Request #18000 · bitcoin/bitcoin · GitHub
19:05:00 <MarcoFalke> Can I exchange mine for #18968 plz
19:05:02 <gribble> https://github.com/bitcoin/bitcoin/issues/18968 | doc: noban precludes maxuploadtarget disconnects by MarcoFalke · Pull Request #18968 · bitcoin/bitcoin · GitHub
19:05:07 <achow101> add ##18971
19:05:09 <wumpus> fjahr: done
19:05:10 <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
19:05:12 <fjahr> And i would like to add #19055 to blockers, it’s the start of #18000 being split up
19:05:14 <gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Calculate UTXO set hash using Muhash by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
19:05:16 <promag> #19033 its tagged for 0.20
19:05:16 <gribble> https://github.com/bitcoin/bitcoin/issues/18000 | [WIP] Index for UTXO Set Statistics by fjahr · Pull Request #18000 · bitcoin/bitcoin · GitHub
19:05:18 <gribble> https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub
19:05:54 <sipa> can i have #18468 ?
19:05:57 <gribble> https://github.com/bitcoin/bitcoin/issues/18468 | Span improvements by sipa · Pull Request #18468 · bitcoin/bitcoin · GitHub
19:06:13 <sipa> also, thanks everyone for getting the serialization improvements in
19:06:18 <sipa> it took a while :)
19:06:19 <wumpus> MarcoFalke: done
19:06:33 <provoostenator> I'd like to nominate #15382
19:06:36 <gribble> https://github.com/bitcoin/bitcoin/issues/15382 | util: add runCommandParseJSON by Sjors · Pull Request #15382 · bitcoin/bitcoin · GitHub
19:06:59 <jonatack> hi
19:07:21 <provoostenator> For code review, but if it gets stuck in another concept discussion, we can bump it to that column.
19:08:36 <wumpus> achow101, sipa, fjahr: added
19:08:44 <wumpus> sipa: yess finally
19:08:46 <sipa> thanks
19:08:50 <fjahr> Thank you!
19:09:26 <MarcoFalke> sipa: Was good that they were split up into reviewable chunks
19:09:32 <wumpus> provoostenator: added
19:09:39 <wumpus> right, that really helped
19:11:16 <wumpus> promag: added
19:11:26 <sipa> MarcoFalke: yes, it really helped; the resulting changes were much better than the original monolithic PR too
19:11:40 <MarcoFalke> #18971 has almost 20 commits and changes 1000 lines of code. that sounds like a whole afternoon of review. I wonder if it can be split up as well
19:11:43 <gribble> https://github.com/bitcoin/bitcoin/issues/18971 | wallet: Refactor the classes in wallet/db.{cpp/h} by achow101 · Pull Request #18971 · bitcoin/bitcoin · GitHub
19:12:09 <achow101> MarcoFalke: I'll look into it
19:12:41 <provoostenator> achow101: MarcoFalke I'm getting used to the behemoths :-)
19:12:51 <wumpus> achow101: great work on the sqlite wallet stuff
19:12:58 <jamesob> if high prio list isn't too full, can add #18637?
19:13:00 <gribble> https://github.com/bitcoin/bitcoin/issues/18637 | coins: allow cache resize after init by jamesob · Pull Request #18637 · bitcoin/bitcoin · GitHub
19:13:30 <MarcoFalke> jamesob: Every contributor is allowed to add one thing, so it's not full yet for you ;)
19:13:44 * sipa spins up his sybils
19:14:02 <wumpus> jamesob: added
19:14:09 <jamesob> thanks maintainers
19:15:22 <wumpus> #topic Separate repository for GUI (MarcoFalke)
19:15:25 <MarcoFalke> Some more background in #19071
19:15:27 <gribble> https://github.com/bitcoin/bitcoin/issues/19071 | [WIP RFC DONOTMERGE] meta: Separate repository for the gui by MarcoFalke · Pull Request #19071 · bitcoin/bitcoin · GitHub
19:16:48 <wumpus> I like the idea at least
19:17:13 <provoostenator> Same, it seems worth a try and easy to reverse.
19:17:15 <MarcoFalke> It is hard to predict if that is going to be benefical for the GUI (Does it increase review or decrease?)
19:17:23 <jnewbery> concept ACK. Haven't thought too much about the approach
19:17:30 <achow101> i feel like that might kill the gui further..
19:17:30 <wumpus> I'd like it to increase contributions mainly
19:17:39 <MarcoFalke> Yes, the change is only "meta" (no build system changes), so it should be trivial to revert
19:17:54 <wumpus> currently it's *scary* to contribute to the GUI being part of the same repository as the consensus code
19:17:55 <MarcoFalke> wumpus: Same, and I think it will.
19:18:00 <wumpus> this turns away some ppl
19:18:04 <jonasschnelli> Yeah. Definitively worth a try.
19:18:28 <jamesob> wumpus: do you really think it actually turns away people, just that GUI is under bitcoin/bitcoin?
19:18:34 <wumpus> jamesob: yes
19:18:36 <MarcoFalke> The GUI review isn't in the best state anyway right now. It can't get much worse tbh
19:18:39 <wumpus> the bar is really high
19:18:51 <provoostenator> It's hard to predict. The smaller Github repo might create more of a critical mass for GUI devs. Or it slows down. But in that case we can undo.
19:18:57 <jamesob> wumpus: but won't process be the same in the GUI "repo"?
19:18:58 <wumpus> MarcoFalke: also true, we could get some more people involed then too
19:19:14 <jonatack> I think the key question is if it will draw new contributors to it.
19:19:42 <wumpus> jamesob: the process, yeah, I guess, but we don't have to have exactly the same team there
19:19:51 <MarcoFalke> jonatack: Even if it didn't draw any new contributors, but the existing ones can more effectively work on core or the gui (or both), then that is already a win, imo
19:19:53 <promag> but in what way does it ease new comers and progress if it's another repo? and at the end its all built together?
19:19:58 <jamesob> afaict all this change (as proposed) accomplishes is segmentation of email/github alerts & issue/PR queues  - and I'm certainly not knocking that
19:20:26 <wumpus> promag: marcofalke's work is one step
19:20:28 <MarcoFalke> jamesob: Yes, it is mostly a meta way to form different notification streams
19:20:39 <wumpus> I think eventually the GUI should evolve faster / partially separate from the rest
19:20:42 <jonasschnelli> The PR/issue separation is IMO already solvable
19:20:55 <promag> isn't it better to do this after multiprocess is in?
19:20:58 <wumpus> but even separating things like issues is probably good
19:21:04 <wumpus> promag: it doesn't matter
19:21:22 <provoostenator> I've _rarely_ used the GUI tag to look for GUI PR's. I don't know if I'm more likely to look at a seperate repo, but I image that I'm reviewing 1 GUI PR, I'm more likely to notice another one.
19:21:46 <wumpus> the current repository just has too wide a scope
19:22:15 <wumpus> it makes sense, conceptually, in the long term to separate things out so why not try to make a little progress
19:22:16 <MarcoFalke> It is not only about the tag, but any kind of communication or notifications
19:22:16 <harding> I think it's important for Bitcoin Core to continue to ship releases with a default GUI, which this allows, and making it easier for people to follow just GUI issues sounds very nice to me, so +1
19:22:25 <jnewbery> promag: there aren't any dependencies between separating GUI into a different repo and multiprocess
19:22:27 <troygiorshev> i can imagine it may help attract people who are more UI/UX focused, and who would be scared away by the breadth of the main repo
19:22:33 <wumpus> harding: yeah what we ship is not going to change
19:23:07 <harding> wumpus: excellent!  I was rather worried about that when I saw the proposed meeting topic.
19:23:07 <gwillen> jnewbery: I was going to kind of ask about the same thing, I imagine that a clean interface separation would make it much easier for people to work on the GUI with confidence about not touching anything in consensus or whatever
19:23:08 <jamesob> troygiorshev: per this proposal, the breadth in terms of code will be the same (which I think may confuse people)
19:23:09 <wumpus> troygiorshev: right
19:23:25 <MarcoFalke> I think the only requirement for this split was the src/interfaces cleanup, because previously the gui directly accessed node globals and state IIRC
19:23:26 <wumpus> gwillen: there is a clear interface separation already
19:23:30 <jnewbery> gwillen: there already is clean interface separation
19:23:45 <wumpus> has been there, for a while
19:24:13 <achow101> I think this will make some wallet improvements harder. the gui almost has direct access to wallet things and some wallet changes have an effect on the gui
19:24:15 <gwillen> I guess a lot of GUI changes do respect that, it's my own fault that my own GUI changes also require changes to that interface and so touch both sides
19:24:40 <achow101> so then you end up with having a wallet change that requires simultaneous gui changes. with 2 repos, that's more difficult
19:24:57 <jnewbery> at the moment, both sides of that interface are in the same process. But everything goes through src/interfaces/node
19:25:01 <promag> but whats the idea? someone clones the gui repo, pulls core somehow and builds eveything?
19:25:15 <gwillen> one thing I see a lot of is the GUI reaching "through" the interface layer to grab a direct pointer to an object on the other side and twiddle it
19:25:27 <gwillen> but anyway maybe this is off the current topic
19:25:29 <wumpus> achow101: for most things the GUI shouldn't care about the *kind* of wallet though
19:26:08 <jnewbery> that interface was introduced a couple of years ago and has been cleaned up continually. If separating the GUI dev process into a separate repo makes us clean it up faster, so much the better!
19:26:11 <wumpus> achow101: e.g. imagine the GUI or some other software accesses the core wallet through RPC, why would it care the wallet was implemented differently?
19:26:27 <MarcoFalke> achow101: If a wallet change has an effect on the gui (e.g. a wallet method was renamed), then that simply goes into the main repo
19:26:28 <sipa> i don't have much of an opinion on the repo separation here... i'm skeptical that it will help, but i agree it's easy to revert if not
19:26:31 <wumpus> achow101: seems also a matter of interface design
19:27:02 <jamesob> it sounds like some people are conflating this proposal with having separate source trees in separate repos; the proposal as-is (IIUC) is to have the same source tree in two separate github repos just to segment github workflow
19:27:03 <promag> adding stuff to core+gui at the same time will take longer too right?
19:27:15 <wumpus> promag: yes
19:27:37 <wumpus> promag: but the preferred flow *already* is, and has been for a long time: implement it in bitcoind, then later add it to the GUI
19:27:45 <MarcoFalke> I also don't think we will see groundbreaking changes, but at least we can gather some data points and experience. And based on those a future "complete" split will be easier to reject or accept.
19:28:08 <sipa> as for better defined interfaces... if the hope is that this will result in more GUI work, and that happens, I expect we'll find out that more work on the GUI will entail more changes to the interface as well... and having things in separate repositories will only complicate things (i realize that this is not what this PR does, but if that's the eventual goal... it can cut both ways)
19:28:26 <jamesob> sipa: agreed
19:28:34 <jnewbery> sipa: sounds like a good problem
19:28:34 <wumpus> I like to split up the repository, ideally I'd like to have started at seperating out consensus code, but we all agree it's much harder than the GUI :)
19:28:39 <achow101> wumpus: I think a specific example of what I'm talking about was with descriptor wallets and watchonly. The GUI had to display different things for descriptor wallets because of the different watchonly behavior, so there needed to be simultaneous wallet and gui changes otherwise the gui would show the wrong thing.
19:28:49 <MarcoFalke> sipa: It is currently not decided if interfaces count to the gui side or the node side
19:28:51 <achow101> I suppose that's more an artifact of legacy wallets though and maybe doesn't matter moving forwards
19:29:08 <sipa> MarcoFalke: node side, obviously?
19:29:13 <jonasschnelli> why would the interface be on the GUI side?
19:29:13 <wumpus> achow101: I agree it will make some things more difficult, though, that seems like a one-time thing
19:29:13 <sipa> they're also used by RPC, no?
19:29:21 <MarcoFalke> are they?
19:29:28 <wumpus> the interface would be node-side, I guess
19:29:32 <MarcoFalke> the rpc directly calls into the node right now
19:29:34 <wumpus> that's the idea of an interface
19:29:36 <jonasschnelli> it's an interface,.. the GUI consumes/adapts to it.
19:29:39 <wumpus> yes
19:29:57 <wumpus> the node defines the interface the GUI uses it
19:30:10 <jnewbery> the rpc doesn't use the interface (but I agree with everyone else that it's part of the node)
19:30:20 <sipa> huh
19:30:23 <wumpus> the GUI can have arbitrary changes as long as the interface doesn't need to change
19:30:24 <jonasschnelli> and since the interface is on the node/core side, I think changing the GUI will be much harder
19:30:31 <wumpus> no, the RPC doesn't use that interface
19:30:35 <wumpus> that doesn't matter here though
19:30:37 <sipa> ok, i never paid attention to the interface side, but i assumed it would be shared between GUI and RPC
19:30:58 <wumpus> RPC is very tightly bound to the node and that's not going to change any time soon
19:31:09 <jamesob> ironic that the guy leading process sep (ryanofsky) isn't saying anything!
19:31:26 <MarcoFalke> silence means ACK, right?
19:31:34 <jamesob> maxim of the law, yes
19:31:44 <jonatack> What were the pain points driving the proposed change? ISTM this isn't clear in the RFC. Lack of GUI review? Other things?
19:31:50 <troygiorshev> is there confusion in where PRs that touch both sides would go?
19:31:52 <jnewbery> but again, process sep is almost completely orthogonal
19:31:57 <wumpus> jonasschnelli: it will make changing the GUI harder *if* it needs an interface change
19:31:59 <provoostenator> Two seperate repos might also make it (slightly) easier to demo more radical forms of splitting the code.
19:32:03 <jamesob> jnewbery: right
19:32:22 <jonasschnelli> MarcoFalke: I'm currently working on a GUI PR that (mempool histogram) that changes the interface.. how would I have to proceed?
19:32:24 <wumpus> jonasschnelli: if it's internal to the GUI, say, moving around some buttons or changing dialogs, not so much, and that's the kind of thing that *needs* to be easier
19:32:26 <provoostenator> troygiorshev: no, they go to the main repo
19:32:51 <jonasschnelli> First PR the interface change (without an consuming element),... then PR the GUI part? Or simultanously... how do we handle the merge?
19:32:59 <promag> wumpus: why? is it hard?
19:33:07 <provoostenator> jonasschnelli: I usually make two PR's that build on eachother
19:33:14 <MarcoFalke> jonasschnelli: Well, everyone except me said that interfaces are node code, so I guess you will have to add the interface first and then make the gui changes
19:33:44 <sipa> jnewbery: i don't know if an outcome where it's easier to make nitty changes, but harder to make substantial changes, is an improvement
19:33:48 <wumpus> yes, you'll have to change the interface first
19:34:02 <wumpus> same as if you were going to change an RPC-facing application and needed some new interface
19:34:03 <jonasschnelli> MarcoFalke: what would be merged first? Or simulatnously?
19:34:03 <MarcoFalke> Obviously this means there will be an unsused method in the interface temporarily, but that should be ok
19:34:10 <gwillen> sipa: well, I think it depends on what your goal is for the GUI
19:34:15 <MarcoFalke> the interface change will be merged first
19:34:24 <gwillen> right now it is clearly a user interface designed by programmers who would rather be doing literally anything other than designing a user interface ;-)
19:34:29 <jonasschnelli> what is the GUI change never gets merged?
19:34:47 <MarcoFalke> It can also be merged at the same time, I guess?
19:34:49 <gwillen> I assume the hope is that separating it means that the GUI can get a lot more work from people who have more expertise in GUIs and less in the backend behind it
19:34:57 <jonasschnelli> If we merge at the same time... do we have really benefits?
19:35:05 <wumpus> jonasschnelli: sure, you'd have to coordinate that
19:35:14 <provoostenator> I hope eventually the GUI and RPC use the same interface, but that's not anytime soon...
19:35:15 <sipa> as an example... btcd started out with separate repos and well-defined interfaces between wallet and node and p2p and ... and after a while they realized it's too much of a pain and moved everything into one repo
19:35:24 <MarcoFalke> jonasschnelli: The majority of GUI changes hopefully don't change the interface
19:35:29 <wumpus> provoostenator: that was always my preference, but it's not going to happen, face it
19:35:30 <sipa> because interesting changes invariable change the interface
19:35:41 <jonasschnelli> ^ +1
19:35:41 <MarcoFalke> I hope the interface converges over time
19:35:51 <jonasschnelli> That would mean the GUI has stalled
19:36:04 <jonasschnelli> (eventually)
19:36:16 <jonasschnelli> (maybe not)
19:36:23 <wumpus> I do think it's absurd to have everything from the consensus code to GUI in the same repo, and would like to change this
19:36:28 <wumpus> but yes where to start
19:36:32 <jamesob> I was going to argue that true repo separation is good because it makes us more likely to screw up the dangerous stuff (consensus, network), but I'm not even sure there's a good argument for that
19:36:34 <sipa> wumpus: yes, i know
19:36:40 <jonasschnelli> wumpus. Yes. I agree.
19:36:41 <ryanofsky> sorry missed earlier discussion, but i think there's a lot of work can get done in gui that doesn't require changing interfaces
19:36:42 <jamesob> *less likely!
19:37:00 <jonasschnelli> But still,... a tiny GUI change can draw the code node down (since everything runs in the same process)
19:37:05 <jonasschnelli> We still have to be careful
19:37:07 <jnewbery> sipa: "if this will result in more GUI work ... more work on the GUI will entail more changes to the interface" is the good problem :)
19:37:15 <wumpus> jonasschnelli: hence the process separation work
19:37:31 <ryanofsky> for changes that do affect interfaces, just submit the pr in the main repo. or if it's easy just add the interface in one pr and use it in a different pr
19:37:31 <promag> how would this benefit new GUIs?
19:37:37 <jonasschnelli> Yes. I just wonder if it would be wiser to seperate the repositories with merging "the" process seprataion
19:37:41 <elichai2> Sipa I can give an example of where it does work. In the rust compiler there's a monorepo that contains most of the complex compiler stuff and it contains submodules of interface tools (static analysis, dynamic analysis, more lints etc) and when a PR changes both repos they're linked together and after ACK on both sides they first merge the compiler side and then the tool's side.
19:38:02 <MarcoFalke> promag: Right now the change does not benefit new GUIs
19:38:14 <wumpus> it's only one step
19:38:18 <wumpus> come on
19:38:36 <jonasschnelli> Yeah. I agree that its worth a try
19:38:47 <jonasschnelli> It might be simpler and more efficient that we initially think.
19:38:48 <MarcoFalke> It is a step in the direction. If we can't get that done, then we shouldn't attempt any further splits imo
19:38:49 <jonasschnelli> Lets try
19:38:49 <achow101> I suppose that if we can easily revert it later then it's fine
19:38:57 <sipa> yeah, this discussion isn't about this PR anymore but more longer-term effects
19:39:01 <jamesob> heck I'm ACK. it'll be easy to revert, and if maintainers want it then so be it - they're the ones who it affects most
19:39:03 <ryanofsky> yeah, it's just a minor step. i can't see how it would help anything that email filtering wouldn't help, but it seems harmless
19:39:12 <sipa> i agree with this because it's so easy to revert
19:39:27 <jonasschnelli> PR/email filtering is easy... that should not be the reason to split off
19:39:40 <wumpus> yes, filtering is easy, that's not the point
19:39:40 <jonasschnelli> review style,.. contributors should it be
19:39:41 <wumpus> delegation is
19:39:45 <jonasschnelli> yes
19:39:50 <wumpus> I don't want to be the bottleneck for everything
19:39:56 <wumpus> certainly not on the long run
19:40:02 <sipa> of course
19:40:03 <jonasschnelli> indeed.
19:40:08 <wumpus> the bitcoi repositry is way too broad
19:40:09 <jb55> I wouldn't say its that easy, there's no way to filter based on labels via email
19:40:11 <elichai2> The downside of "reverting" is losing PRs/Issues history.(by having some of it in a deprecated out of date repo) Altough that's probably not a big deal
19:40:27 <promag> wumpus: right, one step, I'm just wondering about the next steps
19:40:28 <ryanofsky> how is this different than you just filtering out gui-tagged prs and issues?
19:40:33 <provoostenator> I don't even use email for notifications :-)
19:40:35 <wumpus> sigh...
19:40:39 <achow101> elichai2: issues can be moved between repos now. not sure about prs
19:40:56 <elichai2> achow101: you're right. Forgot about that feature
19:40:59 <jamesob> jb55: agree, also curious how people are filtering gui emails out...
19:41:01 <MarcoFalke> elichai2: The same pr (commit hash) can be opened against either repo
19:41:08 <sipa> ryanofsky: someone has to merge things still, and i think wumpus feels responsible for that eventually
19:41:11 <wumpus> yes, how are you even doing that?
19:41:45 <MarcoFalke> I click on "mute conversation" manually on most gui emails
19:41:54 <achow101> isn't jonasschnelli supposed to be the gui maintainer?
19:42:01 <jamesob> achow101: LOL
19:42:03 <jonasschnelli> I try to take care of the GUI prs...
19:42:08 <jonasschnelli> though there are a lot of PR waiting for more reviewers..
19:42:18 <wumpus> currently, yes
19:42:23 <jonasschnelli> or are of isigificance that it doesnt attact reviewers
19:42:25 <jonatack> github-cli now works quite well for filtering things by label
19:42:40 <jnewbery> MarcoFalke: what's the process for merging from the GUI repo to the main repo? Do you propose that it happens immediately after a PR is merged, or do you batch it? Do all of the reviewer ACKs get lost?
19:42:48 <jonasschnelli> if a GUI misses review or maintainer action,.. just point me to it.
19:42:59 <wumpus> I can't be the only person why things it's, in principle, absurd for the GUI to be in the same repository as critical consensus code
19:43:00 <MarcoFalke> jnewbery: The github-merge.py script does it
19:43:11 <jonasschnelli> wumpus: agre
19:43:15 <MarcoFalke> It is instantaneous to both repos, nothing is lost
19:43:25 <jamesob> what is the anticipated burden of rerouting people filing issues/PRs in bitcoin/bitcoin to bitcoin/bitcoin-gui when appropriate?
19:43:35 <MarcoFalke> jonasschnelli: I think #16432 is close to merge (off-topic)
19:43:39 <gribble> https://github.com/bitcoin/bitcoin/issues/16432 | qt: Add privacy to the Overview page by hebasto · Pull Request #16432 · bitcoin/bitcoin · GitHub
19:43:42 <wumpus> but in any case it seems I have a large disconnect with other developers in that regard
19:44:01 <MarcoFalke> jamesob: A linter could do that
19:44:16 <jamesob> wumpus: no I think there's broad agreement there. does *anyone* think that all else equal, gui + consensus is a good thing?
19:44:24 <jonasschnelli> MarcoFalke: indeed... will take a final look
19:44:38 <ryanofsky> MarcoFalke, master branch is effectively mirrored both repos?
19:44:44 <provoostenator> One can make the same argument for the wallet, but that's about the only think I can think of splitting.
19:44:48 <MarcoFalke> ryanofsky: Yes. monotree
19:44:56 <wumpus> jamesob: I don't know, this comes up every few years and it seems besides a few people agreeing, most thing the status quo is okay
19:45:09 <MarcoFalke> The gui repo only has the master branch (or tree)
19:45:17 <wumpus> provoostenator: yes, one can make the same argument for the walet, but that's a discussion for another time
19:45:35 <provoostenator> agreed, GUI is a good place to start
19:45:37 <MarcoFalke> Yes, let's wait with the wallet until at least next year :)
19:45:52 <MarcoFalke> No need to rush
19:46:00 <wumpus> right, need to start somewheere and with some small step
19:46:20 <MarcoFalke> Separation was suggested in 2013. At one point we need to take a small step
19:46:25 <wumpus> yes...
19:46:26 <MarcoFalke> (or even earlier)
19:46:29 <jonasschnelli> heh
19:46:30 <wumpus> 2012 I think
19:46:37 <wumpus> I was ther
19:46:49 <sipa> you wrote the qt gui :p
19:46:57 <MarcoFalke> blame wumpus
19:46:57 <wumpus> biggest mistake in my life
19:47:02 <MarcoFalke> xD
19:47:04 <sipa> no it wasn't
19:47:08 <wumpus> well ,second (but not going into details there)
19:47:09 <jonasschnelli> hah
19:47:14 <jamesob> lol
19:47:18 <jb55> at least it wasn't an electron gui
19:47:22 <sipa> imagine we'd still be stuck on a pre-release wxwindows version
19:47:22 <MarcoFalke> the gui made me contribute to Core
19:47:24 <wumpus> heh
19:47:30 <jonasschnelli> me 2
19:47:43 <jonasschnelli> the GUI is a great module to win new contributors
19:48:02 <aj> jamesob: (consensus and a block-explorer gui; p2p and a p2p gui; and wallet and wallet gui make sense as individual pairs; consensus and wallet gui seem weird, but not an unreasonable consequence of us not having split consensus, p2p and wallet into separate repos)
19:48:05 <wumpus> I'm sorry to not have addressed #17145 though when I could
19:48:06 <gribble> https://github.com/bitcoin/bitcoin/issues/17145 | GUI event loop should be block free · Issue #17145 · bitcoin/bitcoin · GitHub
19:48:07 <jonasschnelli> without the interfaces, it was also easier to learn about the internals
19:48:14 <elichai2> I know dozens of people that run full nodes only because of the gui
19:48:52 <jonasschnelli> wumpus: no worries. Don't blame yourself. Things evolve. No-one would have started everything async in 2011.
19:48:55 <wumpus> I'm glad to hear some people do appreciate it :)
19:49:14 <jb55> elichai2: yeah I mainly use gui now due to the recent psbt/hww features
19:49:14 <jamesob> aj: I see what you're getting at there - but I think the rationale is that consensus is so sensitive that you want it as isolated as is practical
19:49:22 <jonasschnelli> Yeah. We should not underestimate the GUI (even if most of us devs won't use it).
19:50:01 <MarcoFalke> I like the RPC console :)
19:50:08 <MarcoFalke> (10 min left)
19:50:09 <jonasschnelli> m2
19:50:11 <gwillen> jb55: :D that's exciting to hear, and I swear I am going to go rebase #18027 today so you can use it on master :-)
19:50:14 <gribble> https://github.com/bitcoin/bitcoin/issues/18027 | "PSBT Operations" dialog by gwillen · Pull Request #18027 · bitcoin/bitcoin · GitHub
19:50:15 <ariard> side-topic, on altnet, I've started to gather issues here : https://github.com/ariard/altnet-proposals
19:50:37 <wumpus> jamesob: yes, isolating the consensus code would be the other side to start, but it technically much more difficult
19:50:44 * sipa idly wonders if bitcoin 0.4.0 would compile against wxwidget 3.0 (as the 2.9 that was used at the time was never released...)
19:50:45 <ariard> currently in the process talking with people who do actually alt-coms, to learn what could help them
19:51:08 <jb55> gwillen: :+1:
19:51:10 <instagibbs> gwillen, :D
19:51:20 <jamesob> ariard: nice ascii art
19:51:20 <provoostenator> jonasschnelli: without the interfaces, you had no choice but to learn the internals :-)
19:51:29 <jonasschnelli> right!
19:51:43 <MarcoFalke> writing new interfaces will also teach the internals ;)
19:52:17 <gwillen> instagibbs: :D thanks for the reminder about that PR last week, you put it back on my radar, then I avoided replying out of embarrassment
19:52:27 <jonatack> gwillen: nice!
19:52:30 <wumpus> but definitely, if someone was to start designing a GUI nowadays, they'd start with using RPC and an all-async design
19:52:35 <MarcoFalke> And maybe it is a good thing that new gui contributors don't need to learn the cs_main horror
19:52:36 <provoostenator> Looking forward to reviewing that one gwillen
19:53:03 <wumpus> but hey my GUI was better separated from the core code than Satoshi's was…
19:53:04 <promag> MarcoFalke: re separation, all in to help out - still skeptical though
19:53:11 <instagibbs> gwillen, non-0 amount of people including me will use it
19:53:17 <jamesob> "How I Learned to Stop Worrying and Love cs_main"
19:53:32 <jb55> we should bring back the poker client as per satoshi's vision
19:53:56 <MarcoFalke> Also fun draw transaction (requested in 2016)
19:54:05 <sipa> wumpus: you mean it was a problem that main.cpp called into the GUI directly?
19:54:22 <sipa> MarcoFalke: and savage wallet
19:54:25 <wumpus> sipa: heh
19:54:29 <MarcoFalke> what could possibly go wrong?
19:55:04 <jamesob> hey uh by the way when's the next coredev?
19:55:14 <jamesob> should we do something digitally?
19:55:28 <jonasschnelli> in person?! 😱
19:55:35 <MarcoFalke> Wait for the vaccine first, maybe
19:55:54 <instagibbs> jamesob, might be worth asking fulmo folks they've done a few hackathons
19:55:56 <wumpus> at the first next year I guess
19:56:13 <sipa> i don't know how valuable a virtual coredev would be
19:56:20 <wumpus> travel is going to be a mess for a while
19:56:22 <jonasschnelli> we have that already
19:56:24 <MarcoFalke> IRC!
19:56:25 <sipa> i feel IRC is pretty good for communication
19:56:26 <wumpus> yesss
19:56:42 <sipa> in-person is definitely better... but, we'll need to wait for that
19:56:47 <wumpus> I personally don't feel like doing vr or video chat or something
19:57:04 <MarcoFalke> I am certainly not buying VR glasses
19:57:04 <sipa> i like vr meetups... but not for more than 1-2 hours
19:57:18 <jb55> can't get my vr setup working on my linux distro :(
19:57:21 <sipa> and they're more a social thing than a communication thing
19:57:31 <jonasschnelli> yes
19:57:33 <jamesob> right
19:57:36 <jonatack> agree
19:57:39 <jonasschnelli> Lets aim for next year...
19:57:42 <jonasschnelli> plz hawaii. :)
19:57:49 <jnewbery> jonasschnelli: do you mind taking a look at https://github.com/bitcoin/bitcoin/pull/15206#issuecomment-634707439? I like the approach there that moves the header checking to net.cpp and doesn't change behaviour
19:58:04 <jonasschnelli> jnewbery: it's on my list
19:58:05 <jonasschnelli> will do first thing tmr
19:58:06 <wumpus> :D
19:58:14 <jnewbery> great. Thanks!
19:58:54 <promag> facebook has this rooms thing now -.-
19:59:24 <wumpus> concept ACK #15206 somehow missed that one
19:59:24 <gribble> https://github.com/bitcoin/bitcoin/issues/15206 | Immediately disconnect on invalid net message checksum by jonasschnelli · Pull Request #15206 · bitcoin/bitcoin · GitHub
19:59:29 <wumpus> oh I didn't but it's more than a year old hehe
20:00:02 <promag> dong
20:00:04 <jonasschnelli> Yeah.. you concept ACKd long time ago
20:00:06 <wumpus> #endmeeting