From: John Smith <witchspace81@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Thu, 11 Aug 2011 12:19:45 +0000 [thread overview]
Message-ID: <CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4394 bytes --]
next prev parent reply other threads:[~2011-08-11 12:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:36 John Smith
2011-08-10 10:14 ` Matt Corallo
2011-08-10 10:26 ` John Smith
2011-08-10 10:43 ` Pieter Wuille
[not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18 ` John Smith
2011-08-10 16:49 ` Gavin Andresen
2011-08-10 17:45 ` John Smith
2011-08-10 18:41 ` Gavin Andresen
2011-08-10 19:32 ` Andy Parkins
2011-08-10 19:57 ` Jeff Garzik
2011-08-10 21:13 ` Andy Parkins
2011-08-10 21:35 ` Jeff Garzik
2011-08-10 22:38 ` Andy Parkins
2011-08-11 3:20 ` Jeff Garzik
2011-08-11 5:47 ` Andy Parkins
2011-08-11 11:45 ` Joel Joonatan Kaartinen
2011-08-11 12:01 ` Christian Decker
2011-08-11 14:04 ` Andy Parkins
2011-08-11 12:11 ` Mike Hearn
2011-08-11 13:51 ` Andy Parkins
2011-08-11 12:19 ` John Smith [this message]
2011-08-11 13:08 ` Pieter Wuille
2011-08-10 18:43 ` Luke-Jr
2011-08-10 19:48 ` Jeff Garzik
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com' \
--to=witchspace81@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox