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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1SDtBH-0007aG-Ov
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 07:57:03 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=laanwj@gmail.com;
helo=mail-yw0-f47.google.com;
Received: from mail-yw0-f47.google.com ([209.85.213.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1SDtBG-0007Ny-SN
for bitcoin-development@lists.sourceforge.net;
Sat, 31 Mar 2012 07:57:03 +0000
Received: by yhjj56 with SMTP id j56so849073yhj.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 31 Mar 2012 00:56:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.236.173.229 with SMTP id v65mr1004062yhl.85.1333180617504;
Sat, 31 Mar 2012 00:56:57 -0700 (PDT)
Received: by 10.236.175.103 with HTTP; Sat, 31 Mar 2012 00:56:57 -0700 (PDT)
In-Reply-To: <201203310003.18599.luke@dashjr.org>
References: <201203310003.18599.luke@dashjr.org>
Date: Sat, 31 Mar 2012 09:56:57 +0200
Message-ID: <CA+s+GJCzo6GZDyFh8UEy9BNpO7AAZv4NDcEFDAUz=ZEad2=VMQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=20cf3056397120b66104bc854d73
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1SDtBG-0007Ny-SN
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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 07:57:04 -0000
--20cf3056397120b66104bc854d73
Content-Type: text/plain; charset=UTF-8
Thanks for the summary!
On Sat, Mar 31, 2012 at 6:03 AM, Luke-Jr <luke@dashjr.org> wrote:
> 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 ;)
>
Yes, we have a lot of changes waiting already.
> 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.
>
Agreed.
>
> any sort of high-volume bitcoind usage (such as solo mining). Some other
> optimizations by Joel such as the optimized ToHex function (#562) and
>
See my comments there; I'm all for optimizing the ToHex function, but I
prefer that he optimizes the current ToHex function not add yet another one
with an incompatible interface.
(we have the same problem with Error/Debug/"Log to console" functions, too
many of them and sometimes it's unclear what the difference is)
> 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.
>
I also have some UI code changes ready, for example one to use notification
from the bitcoin core when the address book/transactions changed, instead
of a timer. Will submit pull requests soon.
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.
>
Agreed. It is very popular and should certainly be merged. And it has seen
quite some testing already. Though this will take some time to review, as
it is quite a large change.
> 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.
>
>
IPv6 support would be nice, but I don't think a milestone of 0.7 is
realistic. Such a change to the network code will require extensive
testing. Who has access to IPv6 and can help testing?
Wladimir
--20cf3056397120b66104bc854d73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for the summary!<br><br><div class=3D"gmail_quote">On Sat, Mar 31, 2=
012 at 6:03 AM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr=
.org">luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
It seems to me, there is potentially enough ready to merge into 0.7 to star=
t<br>
the RC process right away if someone wants to... except that the first merg=
e<br>
will probably require rebasing everything else ;)<br></blockquote><div><br>=
</div><div>Yes, we have a lot of changes waiting already.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Next up are some changes already ACK'd for 0.7: Hearn's "pong&=
quot; message (#932)<br>
and Wladimir's Visual C++ 2010 fixes (#949). getmemorypool BIP standard=
ization<br>
(#936) is also ACK'd, but it might be good to wait until later in the m=
erge<br>
window considering its low impact and high potential for change as the BIP<=
br>
gets closer to Accepted status.<br></blockquote><div><br></div><div>Agreed.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
any sort of high-volume bitcoind usage (such as solo mining). Some other<br=
>
optimizations by Joel such as the optimized ToHex function (#562) and<br></=
blockquote><div><br></div><div>See my comments there; I'm all for optim=
izing the ToHex function, but I prefer that he optimizes the current ToHex =
function not add yet another one with an incompatible interface.</div>
<div><br></div><div>(we have the same problem with Error/Debug/"Log to=
console" functions, too many of them and sometimes it's unclear w=
hat the difference is)</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
Scott has a pull request for Bitcoin-Qt to behave more like other close-to-=
<br>
systray applications by toggling the hide/show action (#855). He's also=
<br>
contributed a patch to show miners' immature balances on the overview s=
creen<br>
(#837; it leaves only a blank space for non-miners). Nils, on the other han=
d,<br>
has been working with a UI designer to totally remodel Bitcoin-Qt.<br></blo=
ckquote><div><br></div><div>I also have some UI code changes ready, for exa=
mple one to use notification from the bitcoin core when the address book/tr=
ansactions changed, instead of a timer. Will submit pull requests soon.</di=
v>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Coderrr has rebased his Coin =
Control features (#415) to the latest version.<br>
These seem to be popular, so should probably be merged as soon as it's =
had=C2=A0proper review.<br></blockquote><div><br></div><div>Agreed. It is v=
ery popular and should certainly be merged. And it has seen quite some test=
ing already. Though this will take some time to review, as it is quite a la=
rge change.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Finally, I don't know t=
he status of Pieter's IPv6 support, but I hope it will<br>
be ready for 0.7. Right now all I see submitted for this is support for<br>
multiple local IPs (#829) though.<br><br></blockquote><div><br></div><div>I=
Pv6 support would be nice, but I don't think a milestone of 0.7 is real=
istic. Such a change to the network code will require extensive testing. Wh=
o has access to IPv6 and can help testing?=C2=A0</div>
<div>=C2=A0</div><div>Wladimir</div><div><br></div></div>
--20cf3056397120b66104bc854d73--
|
