From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sat, 31 Mar 2012 00:03:17 -0400
User-Agent: KMail/1.13.7 (Linux/3.2.2-gentoo; KDE/4.7.4; x86_64; ; )
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201203310003.18599.luke@dashjr.org>
Subject: [Bitcoin-development] 0.7 merge recommendations/status
Precedence: list

NOTE: I've been piecing this together for about a week now, and intended to 
update it when 0.6.0 final was released, but with the timing of it, I just 
won't get the time to update for a while, so here is my last draft...

It seems to me, there is potentially enough ready to merge into 0.7 to start 
the RC process right away if someone wants to... except that the first merge 
will probably require rebasing everything else ;)

My first recommendation is to merge Matt's CBlockStore (#771). It's mostly a 
major code cleanup, but it still needs a lot of post-merge testing. The sooner 
it gets in the master branch, the more testing of unexpected cases that it 
will get before final. Also, Matt's been working hard to keep rebasing it 
throughout the 0.6 merge window, which is very difficult since it conflicts 
with pretty much every other change. As one of the parties responsible for 
those other changes, I vote to get the big conflict over with and rebase all 
the simpler stuff afterward.

Next up are some changes already ACK'd for 0.7: Hearn's "pong" message (#932) 
and Wladimir's Visual C++ 2010 fixes (#949). getmemorypool BIP standardization 
(#936) is also ACK'd, but it might be good to wait until later in the merge 
window considering its low impact and high potential for change as the BIP 
gets closer to Accepted status.

For similar reasons as CBlockStore, I feel multithreaded JSON-RPC with keep-
alive support (#568) should be merged sooner rather than later. It's long 
overdue for bitcoind having had a lot of testing, and pretty much required for 
any sort of high-volume bitcoind usage (such as solo mining). Some other 
optimizations by Joel such as the optimized ToHex function (#562) and 
FastGetWork (#565) have also had plenty of testing; all combined, these 
optimizations more than double the performance of JSON-RPC.
Details: https://github.com/bitcoin/bitcoin/pull/565#issuecomment-3269334

Pieter's getalltransactions (#841) and my getblock_full (#886) provide what is 
needed to completely replace Jeff's old dumpblock call with bitcoind's new 
getblock. He also put together a -loadblock option (#883) which has proven 
quite handy for development, and -walletupgrade (#974) seems like a good idea.

Under the hood, Chris has some neat refactoring of the coin selection 
algorithm (#905, #898), and I haven't had any problems using it in next-test 
for a few weeks now. Michael has contributed a patch to get the standard 
reopen-log-files-on-SIGHUP (#917). Matt noticed the protocol documentation on 
the wiki and BitcoinJ both expect the 'getheaders' message to return at most 
only 2000 headers, so recommends we enforce that in the core (#951). Philip 
has a trivial flip to the backslashes in debug.log for Windows (#971). Some 
p2pool miners put up a bounty for a JSON-RPC call to customize fee 
requirements (#989) that would help make Bitcoin more decentralized.

Scott has a pull request for Bitcoin-Qt to behave more like other close-to-
systray applications by toggling the hide/show action (#855). He's also 
contributed a patch to show miners' immature balances on the overview screen 
(#837; it leaves only a blank space for non-miners). Nils, on the other hand, 
has been working with a UI designer to totally remodel Bitcoin-Qt.

Coderrr has rebased his Coin Control features (#415) to the latest version. 
These seem to be popular, so should probably be merged as soon as it's had 
proper review.

Finally, I don't know the status of Pieter's IPv6 support, but I hope it will 
be ready for 0.7. Right now all I see submitted for this is support for 
multiple local IPs (#829) though.

I'd like to see Coinbaser (#719) finally get merged, but since it seems nobody 
is using bitcoind for mining anymore, I guess there isn't a real need. I don't 
plan to rebase this anymore unless someone gives it a "I'll merge it" sign.

Luke