< fanquake>
Would anyone be opposed to having a "configuration.md" in /docs/ that explains ./configure usage and dependency -> configure option mappings?
< fanquake>
At the moment there's so much random configure documentation shotgunned all over the place. I think it'd make sense to put it all in one place, and always point back to that from other docs.
< luke-jr>
fanquake: ./configure --help?
< fanquake>
luke-jr: Is your suggestion is to replace every mention of configure options/related info in all the documentation with "go look at ./configure --help"? I don't think that's the answer, unless we want to add a lot more info to that configure output.
< luke-jr>
dunno, aside from dependencies (which have a dedicated doc file) what else is there to say?
< fanquake>
Well at the moment there's configure related suggestions/info spread out all through the build-* files, productivity.md, dependencies.md, developer-notes.md etc. So clearly a fair bit.
< fanquake>
Although a lot of it's repeated, hence why I think consolidating is worthwhile. I'll PR some changes and everyone can take a look.
< fanquake>
I've just merged #16674, however the PR hasn't been auto-closed, and the bot obviously hasn't shown up here. Looking at https://www.githubstatus.com/, it could be a GitHub issue.
< bitcoin-git>
[bitcoin] shargon opened pull request #16678: [validation] static_assert to ensure width in unit class (master...fix-uint) https://github.com/bitcoin/bitcoin/pull/16678
< bitcoin-git>
[bitcoin] shargon closed pull request #16678: [validation] static_assert to ensure width in unit class (master...fix-uint) https://github.com/bitcoin/bitcoin/pull/16678
< bitcoin-git>
[bitcoin] shargon opened pull request #16679: [validation] static_assert to ensure width in unit class (master...fix-unit-base) https://github.com/bitcoin/bitcoin/pull/16679
< bitcoin-git>
bitcoin/master fa8cd6f MarcoFalke: util: Add Join helper to join a list of strings
< bitcoin-git>
bitcoin/master faebf62 MarcoFalke: rpc: Use Join helper in rpc/util
< bitcoin-git>
bitcoin/master 52b9797 MarcoFalke: Merge #16670: util: Add Join helper to join a list of strings
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16670: util: Add Join helper to join a list of strings (master...1908-utilStringJoin) https://github.com/bitcoin/bitcoin/pull/16670
< bitcoin-git>
[bitcoin] jtimon opened pull request #16681: QA: Adapt BitcoinTestFramework for chains other than "regtest" (master...b19-testchains-tests) https://github.com/bitcoin/bitcoin/pull/16681
< emilengler>
How do I write a release note?
< emilengler>
Like is there a file for the upcoming release where PR authors can append their change?
< bitcoin-git>
[bitcoin] jnewbery opened pull request #16682: net_processing: Disconnect blocks-only peers that send us tx INVs (master...2019-08-disconnect-blocksonly-violators) https://github.com/bitcoin/bitcoin/pull/16682
< wumpus>
apparently I wasn't authenticated with freenode so no one was seeing my messages? this was really strange\
< wumpus>
was already surprised why the meetingstart bot wasn't working
< achow101>
how long has wumpus been shouting into the void?
< jonasschnelli>
heh
< meshcollider>
provoostenator has had similar issues before I think
< wumpus>
about five minutes :)
< jeremyrubin>
we miss anything good?
< jonasschnelli>
omg... must have felt terrible
< wumpus>
no, about the same jonasschnelli did :)
< harding>
FYI,I saw "hi" or similar from the following people. If you're not listed, you might be muted. meshcollider jnewbery jonasschnelli provoostenator jeremyrubin ariard sipa dongcarl gleb achow101 (and, just now, wumpus).
< provoostenator>
meshcollider: indeed, that's always fun
< wumpus>
so anyhow, feel free to keep chairing the meeting
< meshcollider>
So far no one has any topics
< jonasschnelli>
Looks like non of the high prio PR's are ready to merge,...
< dongcarl>
#proposedmeetingtopic upgrade to C++17
< jtimon>
hi
< jonasschnelli>
#topic upgrade to C++17 (dongcarl)
< dongcarl>
I looked at the history a little, and there was a PR for upgrading to C++14
< wumpus>
I think no one was prepared for that one
< jeremyrubin>
What are the major new features?
< dongcarl>
I believe that 17 has a lot of functionality that would simplify our codebase
< jeremyrubin>
But IIRC wumpus had some work that was replacing the fs module
< wumpus>
has anyone tried replacing boost filesystem with it in our usage? anything missing?
< ryanofsky>
wumpus, any people you are worried about in particular? i'd expect most non-developers to just use binaries and not be affected
< sipa>
for a long time we had C++11-minus-thread_local as guideline; perhaps there is something similar for C++17 that would bring the compatibility up?
< wumpus>
ryanofsky: I'd like bitcoind to be easily buildable on a wide range of systems such as VPSes and such
< wumpus>
many people build bitcoin from source
< sipa>
i'd like c++17, but not until it's easily supportable on all reasonable systems
< ryanofsky>
so we are worried about the type of person who knows how to build bitcoin from source, but not how to install an updated compiler
< wumpus>
please, installing an updated compiler can be nasty on some platforms
< wumpus>
gcc7 as requirement might be ok, but 8 is not
< ryanofsky>
wumpus, i guess i'm not aware...
< dongcarl>
I'm sorry I misspoke
< sipa>
also, there is a historical case of a miner not wanting to update because he couldn't get a c++11 compatible compiler or something
< wumpus>
I think we should have this discussion on github, not in the meeting
< MarcoFalke>
I'd say that installing a package (compiler or anything) not through a package manager should not be encouraged by us
< dongcarl>
Okay
< ryanofsky>
yeah, it'd be good to know specifics of who would be affected
< jnewbery>
why is this off-topic for a meeting?
< meshcollider>
So C++17-class_template_argument_ddeduction might be ok then
< wumpus>
MarcoFalke:yes it sounds strange to me
< wumpus>
jnewbery: it's not off topic
< wumpus>
but I think this requires a fair amount of research, to see what is affected and what not
< wumpus>
and als o*why* we want this
< wumpus>
and maybe someone actualy implementing the fs stuff using std filesystem and seeing what comes up
< wumpus>
it seem a bit random to just propose 'oh let's bump the requirement to c++17'
< MarcoFalke>
There was an issue on C++14 and it was rejected because centos and similar didn't ship a C++14 compiler. Unless this changes, we don't even need to chat about C++17
< wumpus>
but that might be just me
< sipa>
well when we eventually want to switch to c++17 we will want to discuss it in the meeting
< dongcarl>
I'm sorry, I might be mis-remembering, but in the previous C++14 PR, someone requested for things like this to be discussed in a meeting
< jnewbery>
I think it's useful to solicit opinions in a meeting
< dongcarl>
So that's what I did
< sipa>
but it sounds like we may not have enough information right now
< wumpus>
dongcarl: sure
< dongcarl>
I'll open an issue, we'll discuss there
< jonasschnelli>
ack
< wumpus>
ack, thanks
< jonasschnelli>
I guess it needs a rational. Benefits / risks / user-costs
< wumpus>
right
< jonatack>
hi
< meshcollider>
Centos still has 4.8.5 from what I can see
< MarcoFalke>
jup
< MarcoFalke>
So first we'd need to wait for centos 8 to come out and then give users plenty of time to upgrade
< wumpus>
it'd be too late for 0.19 anyhow, but probably not 0.20 (in half a year) then either
< wumpus>
a reminder that 0.19 release date is getting pretty close, soft string freeze is 2019-09-01, feature freeze 2019-09-15, that's less than a month
< sipa>
thanks
< wumpus>
we probably should start prioritizing features for review that need to make it in for 0.19
< wumpus>
or at least, would be nice to make it in
< MarcoFalke>
quick. Merge all the things!111!!!
< wumpus>
heh
< wumpus>
ok, any other topics?
< wumpus>
#endmeeting
< jonasschnelli>
#endmeeting
< lightningbot>
Meeting ended Thu Aug 22 19:30:33 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< elichai2>
Is it ok to open an issue listing wanted features in 14+17 and then I/we can update current status of compilers and OSs? (and say if these features are even worth it)
< wumpus>
elichai2: sure, but I think dongcarl is opening an issue about it
< dongcarl>
elichai2: I'll link you
< elichai2>
ok dongcarl send the link and i'll comment there :)
< jtimon>
I don't think it belonged in the meeting, but as said, I don't think #8994 needs the "needs conceptual review" tag, while #16524 #16526 and #16527 need it (specially the last 2, since they compete with each other)
< dongcarl>
Is there a better way to terminate message deserialization early (when you encounter absurdities) than to throw an exception in `Unserialize` and catching it in `ProcessMessages`?
< provoostenator>
Sorry for the join/leave noise. Vanity IPv6 address achieved :-)
< provoostenator>
(brushing up my IP tables understandings, because I'm reorganzing my DNS seeds)