< phantomcircuit>
wumpus, one pr per missing thing is probably better
< wumpus>
phantomcircuit: 'better' in what sense?
< phantomcircuit>
less likely to be confusing
< wumpus>
there are already PRs for those issues, I don't think anyone is helped by having another set
< wumpus>
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
< wumpus>
in any csae, that was not my question, it is whether that should end up in master at all
< gmaxwell>
sure, go ahead, I'll redo 7082 on top of it. I'll have to close and reopen 7082 to modify it anyways.
< GitHub73>
bitcoin/master cf82d05 Jorge Timón: Build: Consensus: Make libbitcoinconsensus_la_SOURCES fully dynamic and dependend on both crypto and consensus packages...
< * jtimon>
knows cfields can improve #7091 by avoiding buidling the consensus files too
< jtimon>
s/buidling the consensus files/buidling the consensus files *twice*
< Ylbam>
is a core dev around to answer a bitcoincore.org translation related question?
< Ylbam>
about 2015-12-10 IRC meeting minutes, it was about BIP68
< Ylbam>
^^ morcos
< Ylbam>
I'm trying to understand what is being said in this paragraph of the meeting summary:
< Ylbam>
"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)."