< amiti> wumpus: thanks for the thoughtful reply! helps to hear your outlook, and overall makes sense. I definitely agree with preventing anything dangerous, but questions around flexibility vs usability is more of a gray area. regarding `-connect -dnsseed=1` it seems strange to engage in gossip if you don't actually care about the addresses, but reframing as a question of disabling AddrMan entirely seems like a good
< amiti> bigger-picture direction to engage in
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/54fc96ffa70a...06314fbb5521
< bitcoin-git> bitcoin/master 1b41ce8 Fabian Jahr: lint: Don't use TRAVIS_COMMIT_RANGE for commit-script-check
< bitcoin-git> bitcoin/master c11dc99 Fabian Jahr: lint: Don't use TRAVIS_COMMIT_RANGE in whitespace linter
< bitcoin-git> bitcoin/master a91ab86 Fabian Jahr: lint: Use TRAVIS_BRANCH in lint-git-commit-check.sh
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20071: ci, lint: Remove usage of TRAVIS_COMMIT_RANGE (master...commit_range) https://github.com/bitcoin/bitcoin/pull/20071
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/06314fbb5521...2f7a53cc9d68
< bitcoin-git> bitcoin/master 3491bf3 Wladimir J. van der Laan: test: Mention commit id in scripted diff error
< bitcoin-git> bitcoin/master 2f7a53c MarcoFalke: Merge #20069: test: Mention commit id in scripted diff error
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20069: test: Mention commit id in scripted diff error (master...2020_10_scriptdiff_lint_errormsg) https://github.com/bitcoin/bitcoin/pull/20069
< bitcoin-git> [bitcoin] hebasto closed pull request #20073: [DO NOT MERGE] ci: Print TRAVIS_COMMIT_RANGE before fail (master...201003-travis) https://github.com/bitcoin/bitcoin/pull/20073
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2f7a53cc9d68...f0fd13222621
< bitcoin-git> bitcoin/master 33df8d4 Fabian Jahr: ci: Build Arm64 on Travis without functional tests
< bitcoin-git> bitcoin/master f0fd132 MarcoFalke: Merge #20072: ci: Build Arm64 on Travis without functional tests
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20072: ci: Build Arm64 on Travis without functional tests (master...travis_arm) https://github.com/bitcoin/bitcoin/pull/20072
< wumpus> dhruvm: amiti: yes I mean what I'd like to avoid is a forest of special cases of option combinations that are rejected, because that's hard to maintain, but thinking of the bigger picture around it makes sense
< wumpus> is it just me or is it, with all the buttons and widgets and things that have been added, harder and harder to get to the recent commits list on github
< sipa> wumpus: "git log" works great :)
< wumpus> sipa: sure, it does, it's just slightly amusing that git's (commonly quotes as horrendous) command line interface is starting to look friendly compared to github's how-many-buttons-can-we-fit-per-square inch
< sipa> wumpus: haha, true
< sipa> at some point they'll introduce a CLI console, i'm sure
< wumpus> good idea :)
< wumpus> glad to see the travis commit range issue was sorted out
< sipa> we really need to keep our false positive rate for CI failure low
< sipa> not anyone's fault of course, but this seems to have been tbe result of a cascade, where a bad commit was merged because CI was unreliable, which led to it resulting in even more false positives
< wumpus> the bad commit was merged because the CI didn't run at all for that PR, not because it was unreliable IIRC
< wumpus> in any case I think it was good this came up: it was checking a too-large range of commits, this was bound to be a problem some day
< wumpus> even as say, a performance issue
< wumpus> I agree it's good to keep the false positive rate for CI down, obviously, we're trying ... Travis definitlye doesn't make it easy e.g. the random ARM failures recently
< sipa> yeah :(
< wumpus> AppVeyor also has these random issues where some dependency is upgraded server side ...
< wumpus> I have no clue what is the problem there this time, it's broken at a fairly high level, with everything giving BUILD_FAILURE
< wumpus> oh it confuses even sipsorcery #20066
< gribble> https://github.com/bitcoin/bitcoin/issues/20066 | CI: Appveyor builds failing · Issue #20066 · bitcoin/bitcoin · GitHub
< wumpus> by far most of the failures are outside our control, it rarely happens that we merge something that breaks the build
< sipa> wumpus: some repository we depend on indirectly went offline, it seems?
< sipa> the msys2 thing
< wumpus> yes :/
< fanquake> wumpus: yea that was my stuff up not seeing the missing dash. I thought I'd seen a green tick for Travis as well.
< wumpus> fanquake: yes, that was strange, it has happened before that Travis just doesn't trigger on a PR. I think the only worrying thing is that the scripted diff script in that PR went unchecked now. Did anyone check it manually? If not we probably should.
< sipa> is there a way to make appveyor failures as non-fatal?
< sipa> wumpus: good idea
< sipa> yeah, the diff is trivial
< fanquake> wumpus: I did check locally that the change was complete before merging
< fanquake> was only 4 lines
< sipa> only string changes
< wumpus> fanquake: thanks!
< wumpus> sipa: I'm not sure there's a way to do that, it's definitely been proposed before, but I think github counts all CIs as equal by definition
< wumpus> (which is also why I think we shouldn't add any further ones, it already seems like a slot machine sometimes with these three)
< bitcoin-git> [bitcoin] hebasto opened pull request #20076: doc: Update and improve files.md (master...201004-files) https://github.com/bitcoin/bitcoin/pull/20076
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f0fd13222621...cce151317909
< bitcoin-git> bitcoin/master 675e55e Suhas Daftuar: Ignore unknown messages before VERACK
< bitcoin-git> bitcoin/master cce1513 MarcoFalke: Merge #19723: Ignore unknown messages before VERACK
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19723: Ignore unknown messages before VERACK (master...2020-08-feature-negotiation) https://github.com/bitcoin/bitcoin/pull/19723
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20077: test: Peers avoiding the handshake are disconnected (master...2010-testPeerVerackTimeout) https://github.com/bitcoin/bitcoin/pull/20077
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #20077: test: Peers avoiding the handshake are disconnected (master...2010-testPeerVerackTimeout) https://github.com/bitcoin/bitcoin/pull/20077
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20079: p2p: Ignore non-version msgs before version msg (master...2010-p2pNoVersion) https://github.com/bitcoin/bitcoin/pull/20079
< bitcoin-git> [bitcoin] hebasto opened pull request #20080: Strip any trailing `/` in -datadir path (master...201004-strip) https://github.com/bitcoin/bitcoin/pull/20080
< hebasto> what is currently minimum supported version of Bitcoin Core?
< hebasto> sipa: 0.19.1 right?
< sipa> hebasto: yeah, the 0.19 release series is the last maintained and supported one
< hebasto> sipa: thanks for link and confirmation
< sipa> though it will become unmaintained once 0.21 is released