wumpus, one pr per missing thing is probably better
phantomcircuit: 'better' in what sense?
less likely to be confusing
there are already PRs for those issues, I don't think anyone is helped by having another set
for example it divides up the discussion. Having a clearly labeled backport/forwardport PR can also be handy while writing release notes, e.g. if you want to exclude things that are already in the previous branch
in any csae, that was not my question, it is whether that should end up in master at all
sure, go ahead, I'll redo 7082 on top of it. I'll have to close and reopen 7082 to modify it anyways.
< * jtimon>
knows cfields can improve #7091 by avoiding buidling the consensus files too
s/buidling the consensus files/buidling the consensus files *twice*
is a core dev around to answer a bitcoincore.org translation related question?
about 2015-12-10 IRC meeting minutes, it was about BIP68
I'm trying to understand what is being said in this paragraph of the meeting summary:
"There's some possible issues with the GUI display of currently locked transactions. If a block gets orphaned and a confirmed input becomes unconfirmed it might make a previous acceptable transaction be evicted by the mempool and you might want to inform the user it is locked (as opposed to not visible)."