1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1SDpXF-0005x1-AB
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 04:03:29 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SDpXE-0001bu-5T for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 04:03:29 +0000
Received: from ishibashi.localnet (fl-71-49-115-66.dhcp.embarqhsd.net
[71.49.115.66]) (Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 3A5055606D1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 31 Mar 2012 04:03:22 +0000 (UTC)
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; ; )
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201203310003.18599.luke@dashjr.org>
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1SDpXE-0001bu-5T
Subject: [Bitcoin-development] 0.7 merge recommendations/status
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 31 Mar 2012 04:03:29 -0000
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
|
