diff options
author | Matt Corallo <bitcoin-list@bluematt.me> | 2011-08-11 10:48:09 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-11 08:48:22 +0000 |
commit | e96d8d8f339ed1a8d022d61df795f52ddf429494 (patch) | |
tree | c9f2f63528957491db913820dd6ecb0fcf644bcd | |
parent | a5beda7b36abc7431fdfeb88c1d5cb2831f39022 (diff) | |
download | pi-bitcoindev-e96d8d8f339ed1a8d022d61df795f52ddf429494.tar.gz pi-bitcoindev-e96d8d8f339ed1a8d022d61df795f52ddf429494.zip |
Re: [Bitcoin-development] Roadmap/schedules
-rw-r--r-- | fd/ba975ef13bfcb7fd660495abcba44118f27579 | 149 |
1 files changed, 149 insertions, 0 deletions
diff --git a/fd/ba975ef13bfcb7fd660495abcba44118f27579 b/fd/ba975ef13bfcb7fd660495abcba44118f27579 new file mode 100644 index 000000000..70358d2b6 --- /dev/null +++ b/fd/ba975ef13bfcb7fd660495abcba44118f27579 @@ -0,0 +1,149 @@ +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 <bitcoin-list@bluematt.me>) id 1QrQwA-0006Ce-01 + for bitcoin-development@lists.sourceforge.net; + Thu, 11 Aug 2011 08:48:22 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me + designates 173.246.101.161 as permitted sender) + client-ip=173.246.101.161; + envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; +Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1QrQw6-0001Dr-TA for bitcoin-development@lists.sourceforge.net; + Thu, 11 Aug 2011 08:48:19 +0000 +Received: from [192.168.0.10] (i59F7121B.versanet.de [89.247.18.27]) + by mail.bluematt.me (Postfix) with ESMTPSA id B24072B54 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 11 Aug 2011 10:47:52 +0200 (CEST) +From: Matt Corallo <bitcoin-list@bluematt.me> +To: bitcoin-development@lists.sourceforge.net +In-Reply-To: <CA+8xBpeuzO9+BWZtgpR8h2rSRdB-gQYjq9pyKnbxgBHDX=UnZg@mail.gmail.com> +References: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com> + <CA+8xBpeuzO9+BWZtgpR8h2rSRdB-gQYjq9pyKnbxgBHDX=UnZg@mail.gmail.com> +Content-Type: multipart/signed; micalg="pgp-sha1"; + protocol="application/pgp-signature"; + boundary="=-xfGa2Ti5uc8BMypYniIM" +Date: Thu, 11 Aug 2011 10:48:09 +0200 +Message-ID: <1313052489.20348.5.camel@BMThinkPad.lan.bluematt.me> +Mime-Version: 1.0 +X-Mailer: Evolution 2.32.2 +X-Spam-Score: -2.3 (--) +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 SPF_PASS SPF: sender matches SPF record + -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain +X-Headers-End: 1QrQw6-0001Dr-TA +Subject: Re: [Bitcoin-development] Roadmap/schedules +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, 11 Aug 2011 08:48:22 -0000 + + +--=-xfGa2Ti5uc8BMypYniIM +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> > 3. Wallet security. I'd like to get Matt's wallet encryption shipped +> > soon, along with all or part of groffer's Multisign patch (#319 -- +> > since that will enable the creation of trojan-resistant secure wallet +> > solutions). +>=20 +> IMO the only thing lacking is docs. There is no real admin guide +> describing how to prepare bitcoind installations for encryption; +> doc/README does not mention RPC encryptwallet at all, nor does it +> describe the various states your wallet may be in, when before and +> after encryptwallet has been run. The information is very general, +> and not adequate for a competent admin to be able to evaluate. It +> does not describe encryption method or other security parameters. It +> does not describe the specific technical relationship between the +> master key and other keys. +My fault, Ill write something up on the train back today. +>=20 +> > 5. Testing. I don't have time to personally test every PULL request, +> > but if a pull involves more than trivial code changes I'm not going to +> > pull it unless it has been thoroughly tested. We had a very good rule +> > at a company I used to work for-- programmers were NOT allowed to be +> > the only ones to test their own code. Help finding money and/or people +> > for a dedicated "core bitcoin quality assurance team" is welcome. +> > More unit tests and automated testing is also certainly welcome. +>=20 +> I think Q/A will naturally grow out of some sort of dedicated support +> organization, rather than have a dev fiat requirement. Testing like +> that is always desireable in the "I'd love it, if it were this way" +> vein, but not always realistic at all for open source projects. +> Especially with open source, time has shown that the best testing +> comes from the field, and we have the biggest test lab in the world: +> the Internet. So IMO focus less on roadblocks to publishing software, +> and more on widely distributed test software. +>=20 +> For new features, simple "it works" test at a minimum seems +> reasonable, most of the time. But in open source the testing and such +> tends to happen in the periphery, by organizations and individuals +> with the incentive to focus on those issues. +>=20 +> In my recent emails describing linux-next and a proposed +> "bitcoin-next", one attribute of linux-next is that it is run through +> automated tests on a daily basis, right after the merge is complete. +> It forms a useful layer on top of the primary linux project & tree. +Jenkins + a large enough test suite could do very nice automatic sanity +testing IMHO...that is what it is designed for (even if not to +automatically test pre-merge, but it could be adapted). Many pull +requests build on Linux, but not on MinGW, OSX, etc so just that would +be useful IMHO. +> Not a big deal to me, I never use GUI :) +>=20 +> > Un-hardcode fee handling (anybody already working on this?) +>=20 +> Has anyone actually come up with a good idea to code? +>=20 +> This is a widely acknowledged problem, sure, but where are the good +> solutions, even on paper? +Sipa's stuff is quite good IMHO, it still has some problems left to +solve (like choosing minor details of the underlying priority algorithm) +but aside from those, I think it could work. I'm not sure if sipa wants +to just publish the stuff he did so far and let this list debate on the +remaining details and eventual implementation, or if he wanted to come +up with something complete before publishing, it up to him, but it is +doable. + +Matt + +--=-xfGa2Ti5uc8BMypYniIM +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: This is a digitally signed message part + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQIcBAABAgAGBQJOQ5dIAAoJEBrh01BD4I5UH2YP/RlEsmtqzPMmsCqTeHDPhDuM +489YTZH2hY68Cz4+wJWCrMmBvlmU8MuY4rBOJ6KC31BKhUTGhDunOGrgNTFmnEMf +VsZviNYKu19B2sUTblwVflyIM1DFJ1yLhKjeySO7jxN53wESj2z/SYAdc4FWitN6 +SKMUrDY0CHV3goJoY7zU3PvvzCENfXAmy/JCLyXuU62g0SeyTlEVEJKODAxZSfdi +6fJ5STOpDust9wTWB8bBUZbpC3s596Jur7Kf+hxwY4tk6zVKxuKVap4bBVvDg7uN +DZmfFGyBFp489ifeZb9DGGaYtkdllFeUNcHhRu8gxbkcn53RYBJE7EcEHCgmecxI +2oFu0eZuZ6igyMZ4T0gVF8QgaltYorZQIvid8rrdW6YWVHcxUK49BrsZ5NONdIY7 +flQ2IuzBOiBBkXLIbwa+o2gzUSQ/hS040RQCN/S1FKncP+M1xcQL5ZQXXx0+xkDj +uzE3ez7cBFlaXDe3TL01uuvrrcj55o0poZaekuAP+kAlHvDp9ListCHH7AGGFrxJ +UYmM7BvTBrKB5FG6dRvrSpf+exurBASgsZiv8EQKMC0X7mxrIBykMofWQFgIk2Bx +JrSqg+4/tXppxu3hQ1r9J5S99uoGZ4wAAzCEikmQi5tQl8Y8inmcGvoqlWdFWj0s +7roBcyWtAQMjsPl35Oyv +=JKDl +-----END PGP SIGNATURE----- + +--=-xfGa2Ti5uc8BMypYniIM-- + + + |