< 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
< 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>
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)