< arubi> anyone at all using segnet? I can't find any nodes to connect to. would appreciate an ipv4\tor host I can connect to. thanks.
< btcdrak> arubi: sorted in PM
< arubi> oh, right ^
< GitHub197> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9de541a9c95a...93ca5a35b045
< GitHub197> bitcoin/master 82a0ce0 Suhas Daftuar: Add race-condition debugging tool to mininode
< GitHub197> bitcoin/master 168915e Suhas Daftuar: Eliminate race condition in sendheaders.py test...
< GitHub197> bitcoin/master 93ca5a3 Wladimir J. van der Laan: Merge pull request #7308...
< GitHub163> [bitcoin] laanwj closed pull request #7308: [Tests] Eliminate intermittent failures in sendheaders.py (master...fix-sendheaders) https://github.com/bitcoin/bitcoin/pull/7308
< GitHub56> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/d513405cb71425dd615e88aca4f6222e08d150a5
< GitHub56> bitcoin/0.12 d513405 Suhas Daftuar: [Tests] Eliminate intermittent failures in sendheaders.py...
< GitHub3> [bitcoin] laanwj pushed 3 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/5f09cda0bf4c...00aefccb126f
< GitHub91> [bitcoin] laanwj closed pull request #7259: [0.11] dbwrapper: Detect obfuscation (0.11...MarcoFalke-2015-dbWrapperObfuscation-0.11) https://github.com/bitcoin/bitcoin/pull/7259
< GitHub3> bitcoin/0.11 fa24941 MarcoFalke: [dbwrapper] Detect obfuscation
< GitHub3> bitcoin/0.11 fa3cb49 MarcoFalke: [init] Fix typo
< GitHub3> bitcoin/0.11 00aefcc Wladimir J. van der Laan: Merge pull request #7259...
< MarcoFalke> Luke-Jr, even though a merge commit (or rebase) may appear trivial, I don't think we should put the burden on laanwj to go through that. (Not to mention it is hard to verify if any conflicts were solved during the final merge into bitcoin/bitcoin)
< wumpus> right - I don't do non-trivial merge commits
< wumpus> (except in some rare cases, but in general you should keep your own work up to date)
< MarcoFalke> wumpus,
< MarcoFalke> keypoolrefill is quite expensive, so I think a sleep(1) is enough. Let's make it 1.1 to get another 10 % overhead?
< wumpus> sure
< wumpus> I just don't want to introduce false positives. I've had some bad experiences at a previous employer where a bit of extra load on the test bench caused the test results to light up like a christmas tree, because of tightly timed tests, sending people to chase after nothing every time
< wumpus> using mock time would be ideal, but libevent will ignore that anyway it's a non-starter :)
< Luke-Jr> MarcoFalke: that's not what I said. :p *when* someone is ready to merge, they just need to ping me and I will do the merge
< wumpus> Luke-Jr: can you do your thing for #7081 then?
< Luke-Jr> yep, sec
< * Luke-Jr> peers at github
< Luke-Jr> wumpus: ok done
< Luke-Jr> wumpus: shall I resubmit for 0.12 also?
< MarcoFalke> Luke-Jr, why twice?
< MarcoFalke> Couldn't you just merge 901b01d674031f9aca717deeb372bafa160a24af?
< MarcoFalke> It should slide into master and 0.12, regardless
< Luke-Jr> MarcoFalke: O.o?
< Luke-Jr> wrong commithash?
< MarcoFalke> did you copy the `?`
< Luke-Jr> no
< Luke-Jr> MarcoFalke: got it thx
< wumpus> Luke-Jr: I think so - with a merge commiit in it it's harder to rebase/cherry-pick
< GitHub123> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/93ca5a35b045...dd1304ec216c
< GitHub123> bitcoin/master 45b8e27 Luke Dashjr: -bytespersigop option to additionally limit sigops in transactions we relay and mine
< GitHub123> bitcoin/master fdc202f Luke Dashjr: Merge branch bytespersigop
< GitHub123> bitcoin/master dd1304e Wladimir J. van der Laan: Merge pull request #7081...
< GitHub185> [bitcoin] laanwj closed pull request #7081: -bytespersigop option to additionally limit sigops in transactions we relay and mine (master...bytespersigop) https://github.com/bitcoin/bitcoin/pull/7081
< GitHub115> [bitcoin] luke-jr opened pull request #7323: 0.12: Backport -bytespersigop option (0.12...bytespersigop-0.12.x) https://github.com/bitcoin/bitcoin/pull/7323
< wumpus> I tried to merge fdc202f into 0.12 but that gets a merge conflict in main.cpp
< wumpus> ok
< Luke-Jr> yeah, looks like 0.12 picked up the conflicting change as a cherry-pick or something
< Luke-Jr> btw, ACK/NACK on importing 0.11's test_framework to 0.10 so we can run newer tests against it?
< btcdrak> luke-jr, wumpus: another difficulty with merging topic branches back into master. Topic branches are just better rebased: it's less hassle all round
< wumpus> Luke-Jr: I don't care about 0.10 anymore
< Luke-Jr> btcdrak: disagree; see the links :p
< wumpus> Luke-Jr: but fine with me, if you want to put the effort in
< Luke-Jr> wumpus: ok, so I'll just maintain it myself going forward?
< Luke-Jr> should I move the branch to another repo like I used to, continue to go through PRs, or would it make sense to give me push access just for that branch (not sure if GitHub can enforce)?
< sipa> wumpus: i think that should be announced then
< Luke-Jr> sipa: well, I'll continue to be maintaining it for now either way
< wumpus> sipa: well if Luke-Jr wants to pick it up that's great
< sipa> wumpus: i do think we need some clearly visible policy about which versions the bitcoin core project maintains and will issue bug fix releases for
< wumpus> I just don't have the time to maintain lots of back versions
< sipa> whether that's decided on an ad-hoc basis
< wumpus> but if someone else wants to do that that's great
< wumpus> well in the case of a critical problem I'm sure we can roll a 0.10 release
< Luke-Jr> sipa: can go on a website somewhere maybe? a table with supported/unsupported versions?
< sipa> wumpus: don't get me wrong, i completely agree with not backporting in perpetuity, but i think it is not obvious to the world
< wumpus> but the focus has always been last release + the previous major release, so right now that'ts 0.12 and 0.11
< wumpus> (well, almost)
< wumpus> except in the case of critical security issues
< sipa> ok, what about "After 0.X's branching, 0.X-1 will receive all bug fixes, and 0.X-2 only critical bug fixes"
< wumpus> makes sense to me
< wumpus> except if someone wants to put more work into it like Luke-Jr
< wumpus> but that's all I'm willing to do, yes
< Luke-Jr> makes sense to phrase what sipa said as a "commitment"
< Luke-Jr> anything beyond that is not guaranteed
< sipa> well it's not just about you, but about we as a team commit to doing :)
< cfields> wumpus: just heard back from Travis. They'll be enabling caching for their new infrastructure later this month. That gets us Trusty, docker, and caching.
< sipa> cfields: nice
< wumpus> sipa: I know, but I can only speak for myself
< Luke-Jr> cfields: that requires us to switch to the container-based stuff though, right?
< wumpus> cfields: nice!
< cfields> Luke-Jr: nope, sudo enabled too. So our current config should just work (tm)
< Luke-Jr> sipa: one thing missing in that is with regard to softforks/hardforks
< Luke-Jr> cfields: oh, nice
< cfields> so, I think it makes sense to hold out for that, rather than hacking around too much for now
< sipa> Luke-Jr: well there is a statement around that now on the website
< wumpus> cfields: sure
< sipa> Luke-Jr: but it's not clearly tied to releases
< wumpus> cfields: good to hear it's 'later this month'
< wumpus> cfields: makes no sense to hurry more than that
< Luke-Jr> sipa: once 0.12 is released, even 0.11.x won't likely get sufficient testing, so maybe it's better not to tie it to releases
< Luke-Jr> vague commitment + current status of each branch, seems perhaps ideal?
< MarcoFalke> You mean as a table on the website?
< Luke-Jr> right
< MarcoFalke> makes sense
< wumpus> yes makes sense
< GitHub143> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/d513405cb714...a344880e6ae3
< GitHub143> bitcoin/0.12 5b144b7 Luke Dashjr: Merge branch bytespersigop
< GitHub143> bitcoin/0.12 a344880 Wladimir J. van der Laan: Merge pull request #7323...
< GitHub48> [bitcoin] laanwj closed pull request #7323: 0.12: Backport -bytespersigop option (0.12...bytespersigop-0.12.x) https://github.com/bitcoin/bitcoin/pull/7323
< btcdrak> sipa: wumpus: we should have a maintenance cycle listed somewhere then people know when EOL comes.
< MarcoFalke> And hardcode the EOL into the software?
< MarcoFalke> So a notification could pop up
< Luke-Jr> MarcoFalke: well, EOLing a specific release vs branch is another thing
< Luke-Jr> an automatic internal alert might not be a bad idea, but we need to be careful not to *force* upgrades too
< Luke-Jr> and ideally, it'd be best if people didn't all upgrade at the same time
< Luke-Jr> specific releases tend to be EOL'd unpredictably anyway
< Luke-Jr> ie, "when there is a notable thing to fix"
< wumpus> hardcoding it into the software that goes too far IMO
< wumpus> people are free to upgrade or not upgrade
< MarcoFalke> They may not be aware their sofware is outdated?
< wumpus> but having EOL status on the website is a great idea
< Luke-Jr> MarcoFalke: then they can check..
< Luke-Jr> MarcoFalke: their software won't know it's outdated either
< Luke-Jr> still, it might be good to put a time limit for "hardfork required by now" stuff .. like 2036 :p
< Luke-Jr> someone with push access want to: git tag branch-0.12 3cd836c1d855b92e7c73ab31979f471c4f8dad68 # ? :P
< GitHub10> [bitcoin] luke-jr opened pull request #7324: doc/bips: Document BIP 125 support (master...bips_rbf) https://github.com/bitcoin/bitcoin/pull/7324
< afk11> Anyone running segnet that I can connect up to? and a pool/faucet?
< sipa> afk11: we're going to reset the chain soon (1-2 days, i expect), and then invite more people to connect
< moli> sipa: hi, can segwit be tested in windows?
< sipa> moli: i guess we can do test builds for windows
< moli> sipa: that would be great, thank you
< afk11> sipa: had to step out, but thanks for that.