public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Wed, 10 Aug 2011 20:32:00 +0100	[thread overview]
Message-ID: <201108102032.00373.andyparkins@gmail.com> (raw)
In-Reply-To: <CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>

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



  reply	other threads:[~2011-08-10 19:32 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 [this message]
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
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=201108102032.00373.andyparkins@gmail.com \
    --to=andyparkins@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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