diff options
| author | Jeff Garzik <jgarzik@exmulti.com> | 2011-08-10 16:41:26 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-08-10 20:41:33 +0000 |
| commit | d6e8c05384c717b056bbeeae6fc121ea4e1fdd09 (patch) | |
| tree | 422cbe6e15dee430ae01d4e390f347e18edaaa24 | |
| parent | e0493e2eb1119265cc9b6f15ab41b57cd02491c5 (diff) | |
| download | pi-bitcoindev-d6e8c05384c717b056bbeeae6fc121ea4e1fdd09.tar.gz pi-bitcoindev-d6e8c05384c717b056bbeeae6fc121ea4e1fdd09.zip | |
Re: [Bitcoin-development] Roadmap/schedules
| -rw-r--r-- | 66/badbe1abb24304778dcf653654b9d70f0ac482 | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/66/badbe1abb24304778dcf653654b9d70f0ac482 b/66/badbe1abb24304778dcf653654b9d70f0ac482 new file mode 100644 index 000000000..16912c816 --- /dev/null +++ b/66/badbe1abb24304778dcf653654b9d70f0ac482 @@ -0,0 +1,182 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <jgarzik@exmulti.com>) id 1QrFan-0005kk-5b + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 20:41:33 +0000 +X-ACL-Warn: +Received: from mail-iy0-f171.google.com ([209.85.210.171]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1QrFam-00089Z-3V + for bitcoin-development@lists.sourceforge.net; + Wed, 10 Aug 2011 20:41:33 +0000 +Received: by iyf13 with SMTP id 13so2004586iyf.30 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 10 Aug 2011 13:41:26 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.42.150.69 with SMTP id z5mr3142586icv.67.1313008886747; Wed, + 10 Aug 2011 13:41:26 -0700 (PDT) +Received: by 10.42.226.4 with HTTP; Wed, 10 Aug 2011 13:41:26 -0700 (PDT) +X-Originating-IP: [99.173.148.118] +In-Reply-To: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com> +References: <CABsx9T2pTg8YG_Q09cnAvsrxquLO-6cWr1tb=fdWtLPBEyJzng@mail.gmail.com> +Date: Wed, 10 Aug 2011 16:41:26 -0400 +Message-ID: <CA+8xBpeuzO9+BWZtgpR8h2rSRdB-gQYjq9pyKnbxgBHDX=UnZg@mail.gmail.com> +From: Jeff Garzik <jgarzik@exmulti.com> +To: Gavin Andresen <gavinandresen@gmail.com> +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1QrFam-00089Z-3V +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +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: Wed, 10 Aug 2011 20:41:33 -0000 + +On Wed, Aug 10, 2011 at 12:29 PM, Gavin Andresen +<gavinandresen@gmail.com> wrote: +> 1. Where are we at with network health? What metrics should we be +> using? Is there work to be done? +> And meta-issue: =A0can somebody volunteer to be the Bitcoin Network +> Health Inspector to keep track of this? + +Seems like this would be a useful companion website + project. +bitcoin/networkmon.git could be a central point for contributors to +add various monitors and tests. + +Getting on-going network health information is critical to bitcoin's +success. We need to know if incoming nodes are getting DDoS'd... + +> 2. We've got a chronic problem with new code causing CRITICAL_SECTION +> deadlocks (see issue #453 for the latest). Detecting potential +> deadlocks early should be done; longer term I think re-architecting to +> be single-threaded/asio is probably the right thing to do. + +Agree + +> 3. Wallet security. =A0I'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). + +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. + + +> 4. Bug fixing. =A044 bugs in the issue list, some of which I think are +> already fixed. Anybody else want to volunteer to be BugKeeper? =A0(job +> would be: prioritize/assign bugs, make sure they get closed when +> they're fixed). + +I have never seen an open source project with a successful Bug Czar, +unless that is an actively compensated position. + +> 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. =A0We 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. + +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. + +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. + +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. + +> If this was open source blogging software I'd be much less uptight +> about testing and code review and bugs. But it's not, it is software +> for handling money. + +Although I do agree, remember that it is the nature of open source +that you always have less control than you'd like :) + +If the Iron Fist of Developer Justice squeezes too tightly, people +will simply route around the bottleneck with their own trees and +software releases. genjix is already pushing for his libbitcoin +branch, for example. + +> Stuff I'd like to see in the release-after-next: +> +> fClient mode (download headers only, for faster initial startup; I've +> started the work, talk to me if you want to take over) + +Nice to have, but I think it's just a short term fix. Long term, it +will be SPV clients vs. full nodes, and bringing up a full node will +be so costly that you'll just mirror the block database directly out +of band, then boot the node at 99%+ block height. + +> Sipa's wallet and key export/import + +Yes. I was hoping to get that for 0.4. + +> Move from wxWidgets to qt for the GUI + +Not a big deal to me, I never use GUI :) + +> Un-hardcode fee handling (anybody already working on this?) + +Has anyone actually come up with a good idea to code? + +This is a widely acknowledged problem, sure, but where are the good +solutions, even on paper? + +> Everything else I consider lower priority. But if it is important to +> you, is important to other people (and non-controversial), you +> thoroughly test it, and there's zero chance it introduces a security +> vulnerability... then I'll have no objections to pulling it. +> +> Did I miss anything important? I'll create a Roadmap page on the +> bitcoin wiki if there is general consensus about priorities. + +Parting shot: there is a reason Linus specifically says there is no +roadmap for the kernel. That's because it is always driven by the +community, and like a free market, the collective motivations and +goals of the group. + +Projecting into the future, _and then attempting to stick to that +roadmap_, will end in much frustration. + +Open source contributions are far more organic and unpredictable. +Roadmaps work better in fiat organizations where developers do what +they're paid/told to do :) + +--=20 +Jeff Garzik +exMULTI, Inc. +jgarzik@exmulti.com + + |