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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1TWRsn-0004fa-Pw
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Nov 2012 13:10:57 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.47 as permitted sender)
client-ip=209.85.215.47; envelope-from=laanwj@gmail.com;
helo=mail-la0-f47.google.com;
Received: from mail-la0-f47.google.com ([209.85.215.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TWRsi-0002GZ-6m
for bitcoin-development@lists.sourceforge.net;
Thu, 08 Nov 2012 13:10:57 +0000
Received: by mail-la0-f47.google.com with SMTP id h5so2140448lam.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 08 Nov 2012 05:10:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.114.100 with SMTP id jf4mr7541498lab.47.1352380245482;
Thu, 08 Nov 2012 05:10:45 -0800 (PST)
Received: by 10.112.43.138 with HTTP; Thu, 8 Nov 2012 05:10:45 -0800 (PST)
In-Reply-To: <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com>
References: <CABsx9T1K+XKr=OT5TC4d1KiQ_kXH+giCWHPiS=t7-NyVOmGTDw@mail.gmail.com>
<CAPg+sBisYEMWzS5JNXAoB5EeHc=YboOJqsktEqON1dY6Lo2SsA@mail.gmail.com>
<CANEZrP0LUv69wYwg_6ivPc=mFiGEYKomaJXmmT2Zm14bKik0bQ@mail.gmail.com>
<CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com>
Date: Thu, 8 Nov 2012 14:10:45 +0100
Message-ID: <CA+s+GJCNR503KwyWgfFCAz=LWAShE7+T63mAi_2SqMn+7Fmjhg@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=f46d0408386b221dfd04cdfb90e7
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: 1TWRsi-0002GZ-6m
Subject: [Bitcoin-development] Fwd: IRC meeting agenda, 18:00 UTC Thursday
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: Thu, 08 Nov 2012 13:10:57 -0000
--f46d0408386b221dfd04cdfb90e7
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 8, 2012 at 10:19 AM, Mike Hearn <mike@plan99.net> wrote:
> I won't be able to make it this time. My feeling is IRC is a good place
> to bounce ideas around when time and people happen to be available, but
> having meetings there will inevitably lead to decision making that's better
> done in a slower manner via email.
Well I think regularly scheduled IRC meetings are a good idea, as for some
smaller decisions quick brainstorming tends to work better than long e-mail
threads.
But indeed big and important decisions should be posted on the mailing list
too.
> Comments:
>
> BIP process: are we happy with how it is working? What can we do to improve
> it?
>
> Needing some kind of process to allocate a number is over the top. I
> skipped this for the bloom filtering BIP. We should take off the part of
> the {{BIP}} template that says "don't just pick a number and add a bip" -
> that's exactly what people should do. I'm not sure there's any need for an
> editing role either.
>
Agreed in that we don't need a "number allocation king". But some rules for
the numbering can be good to keep sanity. What about very simply "everyone
that wants to create a BIP picks the next available number and reserves
that page on the Wiki?".
>
> Is it time to feature-freeze 0.8
>
> I'd like more time to get the bloom filtering work in. It'll be easier to
> promote the 0.8 release if we can sell it as "important
> scalability/performance improvement for the network, upgrade to help
> Bitcoin keep growing", as whilst there's no real auto update or organized
> people who religiously update promotion is very important. I think
> ultraprune + bloom filtering is the two major scalability improvements we
> have right now.
>
I'm not sure about a full feature freeze. I agree it could be wise not do
any more changes of the scale of ultraprune before 0.9, to give some
stability to fix the kinks in the current version.
Wladimir
--f46d0408386b221dfd04cdfb90e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote"><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote"><div class=3D"im">On Thu, Nov 8, 2012 at 10:19 AM, Mike Hearn <sp=
an dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik=
e@plan99.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I won't be able to make it this time. =C2=A0My feeling is IRC is a good=
place to bounce ideas around when time and people happen to be available, =
but having meetings there will inevitably lead to decision making that'=
s better done in a slower manner via email.</blockquote>
<div><br></div></div><div>Well I think regularly scheduled IRC meetings are=
a good idea, as for some smaller decisions quick brainstorming tends to wo=
rk better than long e-mail threads.</div><div><br></div><div>But indeed big=
and important decisions should be posted on the mailing list too.</div>
<div class=3D"im">
<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"><div>Comments:</div><div><d=
iv><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">=C2=A0 =C2=A0BIP process: are we happy with how it is working? What can =
we do to=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:=
13px">improve it?</span><br style=3D"font-family:arial,sans-serif;font-size=
:13px">
</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div></div><div><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">Needing some kind of process to allocate a number is over the top.=
I skipped this for the bloom filtering BIP. We should take off the part of=
the {{BIP}} template that says "don't just pick a number and add =
a bip" - that's exactly what people should do. I'm not sure th=
ere's any need for an editing role either.</span></div>
</blockquote><div><br></div></div><div>Agreed in that we don't need a &=
quot;number allocation king". But some rules for the numbering can be =
good to keep sanity. What about very simply "everyone that wants to cr=
eate a BIP picks the next available number and reserves that page on the Wi=
ki?".</div>
<div class=3D"im">
<div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=C2=
=A0 =C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px=
">=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">=
Is it time to feature-freeze 0.8</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">I'd like more time to get the bloom filtering work in. It'll be =
easier to promote the 0.8 release if we can sell it as "important scal=
ability/performance improvement for the network, upgrade to help Bitcoin ke=
ep growing", as whilst there's no real auto update or organized pe=
ople who religiously update promotion is very important. I think ultraprune=
+ bloom filtering is the two major scalability improvements we have right =
now.</span></div>
</blockquote><div><br></div></div><div>I'm not sure about a full featur=
e freeze. I agree it could be wise not do any more changes of the scale of =
ultraprune before 0.9, to give some stability to fix the kinks in the curre=
nt version.=C2=A0</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br></div><div>Wladimir<br></div><div><br></div></font></span></div></=
div>
</div><br>
--f46d0408386b221dfd04cdfb90e7--
|
