It has been a busy month; here's what I'm thinking about:
• It's great to get 0.5 out; congratulations to Wladimir for doing a
great job with the new GUI.
• The wallet encryption bug was embarrassing and stressful, and chewed
up a lot of my time over the past couple of weeks. Bugs happen, but
I've been spending time thinking about what I can do differently to
make it less likely major bugs slip into releases.
Finding the money to hire some professional QA people to help create
test plans and then execute them (the test plans, not the QA people)
is one possible answer. If you have experience finding funding for
open source projects (or know somebody who does) I'd like to talk with
you-- I would much rather spend my time writing code and thinking
about technical issues instead of trying to figure out if advertising
or sponsorship or a Donate menu entry in the client is a reasonable
way to get more testing resources for the project.
Last month I mentioned I was thinking about Organization; there is a
non-profit organization forming to handle Bitcoin PR and marketing,
which takes care of one big area of work.
• The BIP (Bitcoin Improvement Proposal) process seems to be working
well, with good proposals and good discussions (both here and on the
Forums):
https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals
Things I think are high priority but am not planning on working on:
• Implement BIP 14 (separate the protocol and client versions)
• Rework/rethink wallet handling: I think we could do a much better
job with both encryption and backups.
• Work on higher-level multi-signature/multi-device transaction
approval; I really want a version of bitcoin-qt that requires me to
poke an OK button on my iPhone before it can send coins.
• Code clean-up; I'd like to see more small code refactors that moves
non-performance-critical code from .h files to .cpp files, makes
classes more self-contained, etc. Rename the world or change every
single file pull requests are hard to deal with because there is
never a good time to pull them, but a steady stream of makes the
code a little bit easier to work with would be a Good Thing.
Especially if you submit unit tests for whatever you touch...
Thinks I think are high priority and AM planning on working on; if any
of them inspire you, feel free to steal them from me, I still have too
many things on my TODO list:
• Create a pull request for OP_EVAL/multisignature transactions
• Back-port OP_EVAL/multisig to 0.3/0.4 and release patches to make
it easy for the big mining pools to support it, so the network is
ready for multisig/multi-device transactions.
• Work on the 'headers-only' branch, so users have a better first-time
experience.
• I want to start doing some internal re-architecting, and I think
porting my old monitor transactions/blocks patch to use Boost.Signals
might be a good place to start. The internal pieces are pretty
obvious (GUI, database, network, wallet, transaction validation, and
block-chain handling) and I think starting to rearchitect to use
Boost.Signals for internal communications would be a big step towards
more re-usable code.
• Get back to the cross-platform testing infrastructure tool, and lots
of good and bad blockchains that can be used for cross-platform
testing.
I'm probably forgetting several things, but I think that's enough for
now. If you're going to the conference in Prague, have fun! Please
figure out all the hard questions while you're there, and report
back
---
Previous Brain Dump:
https://sourceforge.net/mailarchive/message.php?msg_id=28223657
--
--
Gavin Andresen
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
