summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatt Corallo <bitcoin-list@bluematt.me>2011-08-11 10:48:09 +0200
committerbitcoindev <bitcoindev@gnusha.org>2011-08-11 08:48:22 +0000
commite96d8d8f339ed1a8d022d61df795f52ddf429494 (patch)
treec9f2f63528957491db913820dd6ecb0fcf644bcd
parenta5beda7b36abc7431fdfeb88c1d5cb2831f39022 (diff)
downloadpi-bitcoindev-e96d8d8f339ed1a8d022d61df795f52ddf429494.tar.gz
pi-bitcoindev-e96d8d8f339ed1a8d022d61df795f52ddf429494.zip
Re: [Bitcoin-development] Roadmap/schedules
-rw-r--r--fd/ba975ef13bfcb7fd660495abcba44118f27579149
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--
+
+
+