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
|
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 <gavinandresen@gmail.com>) id 1Qlsy1-00033r-IB
for bitcoin-development@lists.sourceforge.net;
Wed, 27 Jul 2011 01:31:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.43 as permitted sender)
client-ip=209.85.210.43; envelope-from=gavinandresen@gmail.com;
helo=mail-pz0-f43.google.com;
Received: from mail-pz0-f43.google.com ([209.85.210.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Qlsy0-0003Nl-L9
for bitcoin-development@lists.sourceforge.net;
Wed, 27 Jul 2011 01:31:21 +0000
Received: by pzk1 with SMTP id 1so1859785pzk.30
for <bitcoin-development@lists.sourceforge.net>;
Tue, 26 Jul 2011 18:31:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.44.228 with SMTP id h4mr5996225pbm.9.1311730274734; Tue, 26
Jul 2011 18:31:14 -0700 (PDT)
Received: by 10.142.163.9 with HTTP; Tue, 26 Jul 2011 18:31:14 -0700 (PDT)
Date: Wed, 27 Jul 2011 11:31:14 +1000
Message-ID: <CABsx9T3W=n6VVJfOUqcd52oYvd-5hSwdOJudtVHK4g0bPGpXew@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=bcaec520f4b91112db04a903011e
X-Spam-Score: -0.8 (/)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qlsy0-0003Nl-L9
Subject: [Bitcoin-development] Seeking advice: Encouraging bug-fixing over
new features
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, 27 Jul 2011 01:31:21 -0000
--bcaec520f4b91112db04a903011e
Content-Type: text/plain; charset=ISO-8859-1
Anybody have advice on how to encourage more bug-fixing and testing of
existing functionality instead of yet-more-features?
When I get back home from here in Australia I plan on trying to
lead-by-example by starting to tackle the huge backlog of reported bugs, but
I'd like to know if anybody has seen other open source projects successfully
get people to fix bugs instead of constantly adding features. Would policies
like "that spiffy new feature you want won't be considered until you've
helped close some open bugs" be effective (or would it just encourage people
to create shill accounts to open trivial-to-fix issues)?
If this was your run-of-the-mill open source project I would be much
more lackadaisical about letting in new features... but when people lose
money because bugs slip through (and several people HAVE recently lost money
because of bugs slipping through) we obviously have a pretty big problem
just making sure that the features we have now work properly.
(Thanks VERY much to those of you have HAVE been helping test and have been
submitting bug fixes; I don't mean to imply that everybody has been
feature-happy, just that it seems like a lot of potential bitcoin
contributors start out by submitting a nifty new feature that sure would be
nice to have if we weren't so busy trying to make sure the features we
already have work properly all the time).
--
--
Gavin Andresen
--bcaec520f4b91112db04a903011e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Anybody have advice on how to encourage more bug-fixing and testing of exis=
ting functionality instead of yet-more-features?<div><br></div><div>When I =
get back home from here in Australia I plan on trying to lead-by-example by=
starting to tackle the huge backlog of reported bugs, but I'd like to =
know if anybody has seen other open source projects successfully get people=
to fix bugs instead of constantly adding features. Would policies like &qu=
ot;that spiffy new feature you want won't be considered until you'v=
e helped close some open bugs" be effective (or would it just encourag=
e people to create shill accounts to open trivial-to-fix issues)?</div>
<div><br></div><div>If this was your run-of-the-mill open source project I =
would be much more=A0lackadaisical=A0about letting in new features... but w=
hen people lose money because bugs slip through (and several people HAVE re=
cently lost money because of bugs slipping through) we obviously have a pre=
tty big problem just making sure that the features we have now work properl=
y.</div>
<div><br></div><div>(Thanks VERY much to those of you have HAVE been helpin=
g test and have been submitting bug fixes; I don't mean to imply that e=
verybody has been feature-happy, just that it seems like a lot of potential=
bitcoin contributors start out by submitting a nifty new feature that sure=
would be nice to have if we weren't so busy trying to make sure the fe=
atures we already have work properly all the time).</div>
<div><br>-- <br>--<br>Gavin Andresen<br><br>
</div>
--bcaec520f4b91112db04a903011e--
|
