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