MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Roadmap/schedules
Precedence: list

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