1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
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
|
