[Bitcoin-development] State of Bitcoin Development: November Brain Dump

[Bitcoin-development] State of Bitcoin Development: November Brain Dump

[Gavin Andresen]

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

Re: [Bitcoin-development] State of Bitcoin Development: November Brain Dump

[Luke-Jr]

On Monday, November 21, 2011 8:06:27 PM Gavin Andresen wrote:
> 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.

Not prioritizing some unannounced "release schedule" over getting bugs fixed 
before making the release is another part of the answer, at least.