aa24d3e0274861f12e1ea64ef91558a7cd0556
1 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] 2 helo=mx.sourceforge.net) 3 by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) 4 (envelope-from <laanwj@gmail.com>) id 1TWRsn-0004fa-Pw 5 for bitcoin-development@lists.sourceforge.net; 6 Thu, 08 Nov 2012 13:10:57 +0000 7 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com 8 designates 209.85.215.47 as permitted sender) 9 client-ip=209.85.215.47; envelope-from=laanwj@gmail.com; 10 helo=mail-la0-f47.google.com; 11 Received: from mail-la0-f47.google.com ([209.85.215.47]) 12 by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) 13 (Exim 4.76) id 1TWRsi-0002GZ-6m 14 for bitcoin-development@lists.sourceforge.net; 15 Thu, 08 Nov 2012 13:10:57 +0000 16 Received: by mail-la0-f47.google.com with SMTP id h5so2140448lam.34 17 for <bitcoin-development@lists.sourceforge.net>; 18 Thu, 08 Nov 2012 05:10:45 -0800 (PST) 19 MIME-Version: 1.0 20 Received: by 10.152.114.100 with SMTP id jf4mr7541498lab.47.1352380245482; 21 Thu, 08 Nov 2012 05:10:45 -0800 (PST) 22 Received: by 10.112.43.138 with HTTP; Thu, 8 Nov 2012 05:10:45 -0800 (PST) 23 In-Reply-To: <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com> 24 References: <CABsx9T1K+XKr=OT5TC4d1KiQ_kXH+giCWHPiS=t7-NyVOmGTDw@mail.gmail.com> 25 <CAPg+sBisYEMWzS5JNXAoB5EeHc=YboOJqsktEqON1dY6Lo2SsA@mail.gmail.com> 26 <CANEZrP0LUv69wYwg_6ivPc=mFiGEYKomaJXmmT2Zm14bKik0bQ@mail.gmail.com> 27 <CA+s+GJDVLLv8troMfeyWoOwM3EH4GHYtd=bzUgmg_ZegVT6kXw@mail.gmail.com> 28 Date: Thu, 8 Nov 2012 14:10:45 +0100 29 Message-ID: <CA+s+GJCNR503KwyWgfFCAz=LWAShE7+T63mAi_2SqMn+7Fmjhg@mail.gmail.com> 30 From: Wladimir <laanwj@gmail.com> 31 To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> 32 Content-Type: multipart/alternative; boundary=f46d0408386b221dfd04cdfb90e7 33 X-Spam-Score: -0.6 (/) 34 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. 35 See http://spamassassin.org/tag/ for more details. 36 -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for 37 sender-domain 38 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider 39 (laanwj[at]gmail.com) 40 -0.0 SPF_PASS SPF: sender matches SPF record 41 1.0 HTML_MESSAGE BODY: HTML included in message 42 -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from 43 author's domain 44 0.1 DKIM_SIGNED Message has a DKIM or DK signature, 45 not necessarily valid 46 -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 47 X-Headers-End: 1TWRsi-0002GZ-6m 48 Subject: [Bitcoin-development] Fwd: IRC meeting agenda, 18:00 UTC Thursday 49 X-BeenThere: bitcoin-development@lists.sourceforge.net 50 X-Mailman-Version: 2.1.9 51 Precedence: list 52 List-Id: <bitcoin-development.lists.sourceforge.net> 53 List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, 54 <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> 55 List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> 56 List-Post: <mailto:bitcoin-development@lists.sourceforge.net> 57 List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> 58 List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, 59 <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> 60 X-List-Received-Date: Thu, 08 Nov 2012 13:10:57 -0000 61 62 --f46d0408386b221dfd04cdfb90e7 63 Content-Type: text/plain; charset=UTF-8 64 65 On Thu, Nov 8, 2012 at 10:19 AM, Mike Hearn <mike@plan99.net> wrote: 66 67 > I won't be able to make it this time. My feeling is IRC is a good place 68 > to bounce ideas around when time and people happen to be available, but 69 > having meetings there will inevitably lead to decision making that's better 70 > done in a slower manner via email. 71 72 73 Well I think regularly scheduled IRC meetings are a good idea, as for some 74 smaller decisions quick brainstorming tends to work better than long e-mail 75 threads. 76 77 But indeed big and important decisions should be posted on the mailing list 78 too. 79 80 81 > Comments: 82 > 83 > BIP process: are we happy with how it is working? What can we do to improve 84 > it? 85 > 86 > Needing some kind of process to allocate a number is over the top. I 87 > skipped this for the bloom filtering BIP. We should take off the part of 88 > the {{BIP}} template that says "don't just pick a number and add a bip" - 89 > that's exactly what people should do. I'm not sure there's any need for an 90 > editing role either. 91 > 92 93 Agreed in that we don't need a "number allocation king". But some rules for 94 the numbering can be good to keep sanity. What about very simply "everyone 95 that wants to create a BIP picks the next available number and reserves 96 that page on the Wiki?". 97 98 99 > 100 > Is it time to feature-freeze 0.8 101 > 102 > I'd like more time to get the bloom filtering work in. It'll be easier to 103 > promote the 0.8 release if we can sell it as "important 104 > scalability/performance improvement for the network, upgrade to help 105 > Bitcoin keep growing", as whilst there's no real auto update or organized 106 > people who religiously update promotion is very important. I think 107 > ultraprune + bloom filtering is the two major scalability improvements we 108 > have right now. 109 > 110 111 I'm not sure about a full feature freeze. I agree it could be wise not do 112 any more changes of the scale of ultraprune before 0.9, to give some 113 stability to fix the kinks in the current version. 114 115 Wladimir 116 117 --f46d0408386b221dfd04cdfb90e7 118 Content-Type: text/html; charset=UTF-8 119 Content-Transfer-Encoding: quoted-printable 120 121 <div class=3D"gmail_quote"><div class=3D"gmail_extra"><br><div class=3D"gma= 122 il_quote"><div class=3D"im">On Thu, Nov 8, 2012 at 10:19 AM, Mike Hearn <sp= 123 an dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik= 124 e@plan99.net</a>></span> wrote:<br> 125 <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= 126 x #ccc solid;padding-left:1ex"> 127 I won't be able to make it this time. =C2=A0My feeling is IRC is a good= 128 place to bounce ideas around when time and people happen to be available, = 129 but having meetings there will inevitably lead to decision making that'= 130 s better done in a slower manner via email.</blockquote> 131 132 <div><br></div></div><div>Well I think regularly scheduled IRC meetings are= 133 a good idea, as for some smaller decisions quick brainstorming tends to wo= 134 rk better than long e-mail threads.</div><div><br></div><div>But indeed big= 135 and important decisions should be posted on the mailing list too.</div> 136 <div class=3D"im"> 137 <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= 138 ex;border-left:1px #ccc solid;padding-left:1ex"><div>Comments:</div><div><d= 139 iv><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p= 140 x">=C2=A0 =C2=A0BIP process: are we happy with how it is working? What can = 141 we do to=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:= 142 13px">improve it?</span><br style=3D"font-family:arial,sans-serif;font-size= 143 :13px"> 144 145 146 </div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= 147 </span></div></div><div><span style=3D"font-family:arial,sans-serif;font-si= 148 ze:13px">Needing some kind of process to allocate a number is over the top.= 149 I skipped this for the bloom filtering BIP. We should take off the part of= 150 the {{BIP}} template that says "don't just pick a number and add = 151 a bip" - that's exactly what people should do. I'm not sure th= 152 ere's any need for an editing role either.</span></div> 153 154 </blockquote><div><br></div></div><div>Agreed in that we don't need a &= 155 quot;number allocation king". But some rules for the numbering can be = 156 good to keep sanity. What about very simply "everyone that wants to cr= 157 eate a BIP picks the next available number and reserves that page on the Wi= 158 ki?".</div> 159 <div class=3D"im"> 160 <div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 161 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> 162 <div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span= 163 ></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">=C2= 164 =A0 =C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px= 165 ">=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">= 166 Is it time to feature-freeze 0.8</span></div> 167 168 169 <div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span= 170 ></div></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p= 171 x">I'd like more time to get the bloom filtering work in. It'll be = 172 easier to promote the 0.8 release if we can sell it as "important scal= 173 ability/performance improvement for the network, upgrade to help Bitcoin ke= 174 ep growing", as whilst there's no real auto update or organized pe= 175 ople who religiously update promotion is very important. I think ultraprune= 176 + bloom filtering is the two major scalability improvements we have right = 177 now.</span></div> 178 179 </blockquote><div><br></div></div><div>I'm not sure about a full featur= 180 e freeze. I agree it could be wise not do any more changes of the scale of = 181 ultraprune before 0.9, to give some stability to fix the kinks in the curre= 182 nt version.=C2=A0</div> 183 <span class=3D"HOEnZb"><font color=3D"#888888"> 184 <div><br></div><div>Wladimir<br></div><div><br></div></font></span></div></= 185 div> 186 </div><br> 187 188 --f46d0408386b221dfd04cdfb90e7-- 189 190