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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QrUEq-0005Lu-EB
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 12:19:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1QrUEp-0008RX-Gi
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 12:19:52 +0000
Received: by yxi19 with SMTP id 19so1588069yxi.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 05:19:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.31.13 with SMTP id e13mr535185ybe.174.1313065185977; Thu,
11 Aug 2011 05:19:45 -0700 (PDT)
Received: by 10.150.52.5 with HTTP; Thu, 11 Aug 2011 05:19:45 -0700 (PDT)
In-Reply-To: <CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
<20110810104316.GA30749@ulyssis.org>
<CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
<CAJNQ0stkZ=iBCJA7E5+LZToe2MjEJnhqWoiUtLcqTGPygSikiA@mail.gmail.com>
<CABsx9T0Yvssr04AeT3B8+Gj43hV=P0Uw6M0f+NBNygnAyruQ4A@mail.gmail.com>
<CAJNQ0stfYFN2YCGq-be5D-XW+81ZkVVM_jHHonSy2OHsNyN1Cw@mail.gmail.com>
<CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
Date: Thu, 11 Aug 2011 12:19:45 +0000
Message-ID: <CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd35788fa274a04aa39cf2c
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrUEp-0008RX-Gi
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Change to multiple executables?
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: Thu, 11 Aug 2011 12:19:52 -0000
--000e0cd35788fa274a04aa39cf2c
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Aug 10, 2011 at 6:41 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:
>
> Well, to be honest I don't think more developers adding new features
> are needed right now-- I think the project's critical needs are more
> people testing and helping to fix bugs and scalability issues.
>
I do think to be an successful open source project we need more developers
and more features. Activity is very important, it is kind of the lifeblood.
Yes, a project will generally become more stable and slow in time as it
nears "perfection" (or at least, a local optimum) but the current source is
*far* from that.
Yes -- bugs and scalability issues need to be addressed, but this will be a
lot easier if some underlying problems are solved. And if we ignore the end
users, they may run away and it becomes a pointless exercise.
Taking the "long view" this includes build system, handling of
threads/concurrency, modularization, pluggable DB and storage back-ends,
separating the system into multiple "locked-down" processes, and so on.
This can all be done while remaining P2P-compatible for as long as possible
(we have versioning, don't we?).
My proposal with multiple branches was about looking at the long view as
well as the immediate firefighting. Yes, some changes might be riskier than
others, but we can't just cargo-cult Satoshi's work forever... so with
multiple branches, people can choose whether they have the balls to try
something newer or just want to run the older version with the issues they
know and love.
It's better to be open. Look at Open Office, it only started to un-stagnate
when it was forked out of Oracle's stranglehold. People want to work on
these things, so why not?
Until this is addressed, developers will prefer creating their own fork or
even alternative client. After this UI stuff is handled I'll probably join
up with one of them.
> In this particular case, I said I was mildly against it-- if you want
> me to switch to supporting it, then reassure me you're willing to do
> ALL the work to make it happen. Send me a list of wiki pages you'll
> edit to document the change and tell me that you'll be around to help
> people rewrite their backup scripts.
IMO this should have been your first reply, instead of first discourgaging
me from doing it. Just make a list of what needs to be done.
But I won't bother anymore... Let's just keep lumping everything in one
executable. It's the Satoshi way.
On Wed, Aug 10, 2011 at 7:32 PM, Andy Parkins <andyparkins@gmail.com> wrote:
> Of course, nothing forces existing developers to accept these new
features;
> but the incredibly negative attitude on display when any new feature is
> suggested is not the way to grow a community. The correct way is a
> mentoring attitude -- offering opinions on how a new developer can get
their
> idea in rather than telling them why it will never happen.
Exactly. My gripe is more about the negative attitude then anything else.
The focus is always on the negative sides of every proposal, a bit of a
climate of fear.
I've had an employer that worked in the same way. Eternally hammering on
"stability" the codebase, hiring 100's of extra developers, all firefighting
and fixing immediate issues with "priority", the code became a minefield.
Even with 8 hours of testcases, the overall structure of the code caused so
many issues that customers feared every new release more. A classic negative
feedback loop.
I understand where it is coming from, many people just come and dump their
"ideas" and never implement a line of code. But if people are actually
proposing to implement something, or implemented it, they should IMO be
given the benefit of the doubt. Not all outside ideas are bad.
JS
--000e0cd35788fa274a04aa39cf2c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On Wed, Aug 10, 2011 at 6:41 PM, Gavin Andre=
sen <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com">gavina=
ndresen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
</div>Well, to be honest I don't think more developers adding new featu=
res<br>
are needed right now-- I think the project's critical needs are more<br=
>
people testing and helping to fix bugs and scalability issues.<br></blockqu=
ote><div><br>I do think to be an successful open source project we need mor=
e developers and more features. Activity is very important, it is kind of t=
he lifeblood. Yes, a project will generally become more stable and slow in =
time as it nears "perfection" (or at least, a local optimum) but =
the current source is *far* from that.<br>
<br>Yes -- bugs and scalability issues need to be addressed, but this will =
be a lot easier if some underlying problems are solved. And if we ignore th=
e end users, they may run away and it becomes a pointless exercise.<br>
<br>Taking the "long view" this includes build system, handling o=
f threads/concurrency, modularization, pluggable DB and storage back-ends, =
separating the system into multiple "locked-down" processes, and =
so on.=A0 This can all be done while remaining P2P-compatible for as long a=
s possible (we have versioning, don't we?).<br>
<br>My proposal with multiple branches was about looking at the long view a=
s well as the immediate firefighting.=A0 Yes, some changes might be riskier=
than others, but we can't just cargo-cult Satoshi's work forever..=
. so with multiple branches, people can choose whether they have the balls =
to try something newer or just want to run the older version with the issue=
s they know and love.<br>
<br>It's better to be open. Look at Open Office, it only started to un-=
stagnate when it was forked out of Oracle's stranglehold. People want t=
o work on these things, so why not?<br><br>Until this is addressed, develop=
ers will prefer creating their own fork or even alternative client. After t=
his UI stuff is handled I'll probably join up with one of them.<br>
<br>
> In this particular case, I said I was mildly against it-- if you want<=
br>
> me to switch to supporting it, then reassure me you're willing to =
do<br>
> ALL the work to make it happen. =A0Send me a list of wiki pages you=
9;ll<br>
> edit to document the change and tell me that you'll be around to h=
elp<br>
> people rewrite their backup scripts.<br>
<br>IMO this should have been your first reply, instead of first discourgag=
ing me from doing it. Just make a list of what needs to be done.<br><br>But=
I won't bother anymore... Let's just keep lumping everything in on=
e executable. It's the Satoshi way.<br>
<br>On Wed, Aug 10, 2011 at 7:32 PM, Andy Parkins <span dir=3D"ltr"><<a =
href=3D"mailto:andyparkins@gmail.com">andyparkins@gmail.com</a>></span> =
wrote:<br>
> Of course, nothing forces existing developers to accept these new feat=
ures;<br>
> but the incredibly negative attitude on display when any new feature i=
s<br>
> suggested is not the way to grow a community. =A0The correct way is a<=
br>> mentoring attitude -- offering opinions on how a new developer can =
get their<br>
> idea in rather than telling them why it will never happen.<br>
<br>Exactly. My gripe is more about the negative attitude then anything els=
e.=A0 The focus is always on the negative sides of every proposal, a bit of=
a climate of fear. <br>
<br>I've had an employer that worked in the same way. Eternally hammeri=
ng on
"stability" the codebase, hiring 100's of extra developers, =
all=20
firefighting and fixing immediate issues with "priority", the cod=
e=20
became a minefield. Even with 8 hours of testcases, the overall=20
structure of the code caused so many issues that customers feared every=20
new release more. A classic negative feedback loop.<br><br>I understand whe=
re it is coming from, many people just come and dump their "ideas"=
; and never implement a line of code. But if people are actually proposing =
to implement something, or implemented it, they should IMO be given the ben=
efit of the doubt. Not all outside ideas are bad.<br>
<br>JS<br><br></div></div>
--000e0cd35788fa274a04aa39cf2c--
|
