Even though I know that splitting up the massive bitcoin/bitcoin repo is going to be better in the long term. Sometimes I feel like I'm losing a handle on everything that gets split out. Especially what's in the bitcoin-core/docs repo. Haven't reviewed any of the recent gitian build guide changes.
wumpus #13141 is trivial and mergeable.
/bitcoin was where bitcoin was migrated to from SF. /bitcoin-core houses some core specific repos such as the website, docs etc
right - bitcoin is the legacy organization, bitcoin-core is where most of the repositories have been moved
oh ok, so it's just a legacy thing. i didn't know if they two orgs were supposed to have different purposes, or were run by different people or something
it was originally the plan to move the bitcoin repository too, however since the 'bitcoin core' as currency name bullshit from BCHers, that's probably a bad idea and will only contribute towards user confusion
well except bips, which will probably always stay in bitcoin
yes, or a 'bips' organization
The crossover between the "teams" in the two orgs is pretty high. Probably just a few more inactive/older users in /bitcoin
yes, if you're in bitcoin but not in bitcoin-core or vice versa, let me know, invites are supposed to go out for both at the same time
bitcoin/master 73bc1b7 practicalswift: Initialize editStatus and autoCompleter. Previously not initialized where defined or in constructor.
bitcoin/master f131872 practicalswift: Initialize non-static class members where they are defined
bitcoin/master 1e7813e practicalswift: Remove redundant initializations from the constructor
[bitcoin] laanwj closed pull request #12928: qt: Initialize non-static class members that were previously neither initialized where defined nor in constructor (master...qt-constructors) https://github.com/bitcoin/bitcoin/pull/12928
hm is this expected that v0.16.0 crashes on start with built with --with-incompatible-bdb ? this issues are closed #6775 (and #12047). System always had libdb5.3 never had libdb4.x (Debian testing 10 from installation)
[bitcoin] practicalswift closed pull request #12665: Add compile time checking for run time locking assertions (master...compile-time-checking-of-runtime-assertions) https://github.com/bitcoin/bitcoin/pull/12665
are there any caveats we know of re: usage of std::mutex/std::lock_guard on windows? I'm seeing some weird unhandled page faults only on windows with pretty vanilla usage of these constructs
jamesob: care to create a minimal reproduction?
sipa: yeah, I might have to go down that road