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
|
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 <calebdelisle@lavabit.com>) id 1QmSXk-0006VF-ER
for bitcoin-development@lists.sourceforge.net;
Thu, 28 Jul 2011 15:30:36 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QmSXj-0002oL-NK for bitcoin-development@lists.sourceforge.net;
Thu, 28 Jul 2011 15:30:36 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id CD20711BAC4
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 Jul 2011 10:30:29 -0500 (CDT)
Received: from 192.168.1.2 (pool-74-106-82-125.spfdma.east.verizon.net
[74.106.82.125]) by lavabit.com with ESMTP id ZZOMG3VBLELO
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 Jul 2011 10:30:29 -0500
Message-ID: <4E318231.9020707@lavabit.com>
Date: Thu, 28 Jul 2011 11:37:21 -0400
From: Caleb James DeLisle <calebdelisle@lavabit.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:2.0b9pre) Gecko/20110109 Thunderbird/3.3a2pre
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABsx9T3W=n6VVJfOUqcd52oYvd-5hSwdOJudtVHK4g0bPGpXew@mail.gmail.com>
<1311765274.9830.3.camel@mei>
<CAJNQ0su9Qbi=zMaJA0G77UuHkXBy8k7YLBd4cec=Rc_-FGPBjA@mail.gmail.com>
<201107271028.28057.luke@dashjr.org>
<CAJ1JLtuuUUmrWGScbvYikAY_FOQhWpX5bt1NGp8VkpHk-hHOsQ@mail.gmail.com>
<1311786944.9830.77.camel@mei>
<CABsx9T1667dxUj_iRtgbUR0ymBVOaADkGQU_CMF7z7e1-ctRcQ@mail.gmail.com>
<CA+8xBpcKNrGFKkN4mAW9E_s9Ph1=Qh9DNWryihDmD90HWMWF3Q@mail.gmail.com>
In-Reply-To: <CA+8xBpcKNrGFKkN4mAW9E_s9Ph1=Qh9DNWryihDmD90HWMWF3Q@mail.gmail.com>
X-Enigmail-Version: 1.2a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.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 SPF_PASS SPF: sender matches SPF record
-1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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
X-Headers-End: 1QmSXj-0002oL-NK
Subject: Re: [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: Thu, 28 Jul 2011 15:30:36 -0000
Bitcoin seems to have a relatively unique problem, there is a perception that there are early adopters who still have large stashes of btc.
Not that this is wrong, they knew a good thing early, the problem is that it is hard for someone (me) to justify volunteering work on a codebase which will directly benefit other people even if they do nothing.
From my brief observation it appears that the developers now are split between early adopters who are working on their investment, ambitious people who are working on alt clients to satisfy certain requirements for their own projects and hobby developers donating code to alt chain clients because chains which have not taken off don't benefit anyone yet.
As far as trying to bring these people together, I don't have any silver bullet answers but I think there needs to be some kind of sponsorship of developers. I2P uses bounties but they are indeed a small community, I can see bounties going very wrong but I suppose it doesn't hurt to experiment. I think grants for active developers make more sense, then we only need someone to decide who is active enough.
Also moving in the direction of seperating bitcoin the program from Bitcoin the blockchain and accepting patches for merged mining and alt chain stuff which doesn't directly benefit Bitcoin would help decrease the "people are making money off of my back" feeling that (IMO) stands in the way of new developers.
Caleb
On 07/27/2011 08:15 PM, Jeff Garzik wrote:
> Linux kernel has not solved this problem; developers simply want to
> work on interesting stuff, rather than debug, I think.
>
> The best Linus has done so far it making certain periods of time
> bugfix-only, refusing to take new feature pushes during the stability
> period. If there are critical bugs, refusing to release the kernel
> until a developer fixes the regressions they added.
>
> Linux is large enough, though, that the ecosystem has grown a support
> network, where companies pay for support (one big way my employer
> stays in business), which includes bug fixes. So the paid support
> orgs, like Red Hat, wind up going a lot of grunt work fixing because
> they are the closest contact to actual users in the field encountering
> problems with the Wonderful New Features bestowed upon them by
> developers.
>
> "drop and run" coding is a term for developers who appear, commit a
> new feature, and then disappear without addressing bug reports or
> other feedback regarding their contribution.
>
|
