Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.47 as permitted sender)
	client-ip=209.85.215.47; envelope-from=andyparkins@gmail.com;
	helo=mail-ew0-f47.google.com; 
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 10 Aug 2011 20:32:00 +0100
User-Agent: KMail/1.13.6 (Linux/2.6.39-2-686-pae; KDE/4.6.4; i686; ; )
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
	<CAJNQ0stfYFN2YCGq-be5D-XW+81ZkVVM_jHHonSy2OHsNyN1Cw@mail.gmail.com>
	<CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
In-Reply-To: <CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201108102032.00373.andyparkins@gmail.com>
Subject: Re: [Bitcoin-development] Change to multiple executables?
Precedence: list

On Wednesday 10 August 2011 19:41:51 Gavin Andresen wrote:
> > To be honest I feel a bit like every change that I (and I've also heard
> > this from others) propose is shot down, no matter how well
> > formulated.  This is actively discouraging developers from joining
> > this project.
> 
> 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.

(Rant follows; stop reading now)

That paragraph reveals a gross misunderstanding of how open source works.  

People get itches and they want to scratch them.  They aren't paid, so they 
don't necessarilly want to turn up and be told which part they _should_ be 
working on.  The choice is not "bug fix that Gavin wants" or "new feature 
that New Developer wants", it is "New Feature" or nothing.

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.

> I don't see how dividing efforts between a 'bug fix' and 'development'
> branch will help fix the project's critical needs. If we did, I think

Again: that's not your call.  People will work on what interests them.  I've 
suggested a couple of features both here and on the forum and been shot down 
in varying degrees every time.  Fine, but don't expect that I'm thinking 
"well I'll become an unpaid bug fixing grunt instead".

I don't expect to be appointed head developer because I suggest an idea.  I 
don't even expect anyone else to implement my idea for me.  But why should I 
spend time on my own idea when the feedback is "no", "no", "we've already 
thought of that", "not needed", "go away", "why not fix some bugs instead"?

I'm amazed that John Smith is as polite and persistent as he is looking at 
the amount of effort he's put in putting a pretty face on the train crash 
that existed before hand and seems to get no benefit of the doubt for his 
work.

> there would be less pressure to help with the boring bug-fixing and
> testing of the bug-fix branch, which I think would be bad.

That pressure might be relieved if the community were able to grow a bit, 
and people felt they had a personal investment.  That means loosening the 
reigns a bit; and perhaps a development branch would be the way to do that 
while not compromising code quality.

I suggest a look at the way git itself is developed; it has the following 
branches:

 - master: the latest release + newly accepted features
 - maint: the latest release + bug fixes only
 - next: new features planned for inclusion, actively being worked on.
   Often created by merging "topic" branches from individual developers
   working on their current itch
 - pu: crazy stuff; not planned for inclusion, but acting as a staging
   area for people to show what they're working on


Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com