Switching from CVS to Subversion: test svn repo available

[Chris Shoemaker]

On Mon, Oct 24, 2005 at 01:20:11PM -0400, Derek Atkins wrote:
> Quoting Brian <dol-sen at telus.net>:
> 
> >>My point is not so much "distributed is better than centralized", as
> >>it is "lower the barriers to new developers by letting them share code
> >>early and often."  Distributed SCM is *one* way to do that.
> >
> >I agree with with Chris on this one.  I am not much of a developer, but
> >would like to contribute when I can.  Several months back I tried making
> >changes to make the hard coded business info in the fancy-invoice
> >dynamic.  I was able to extend the File=>Properties dialog and get the
> >additional data saved and reloaded, but could not get the fancy-invoice
> >to retreive that data.  (Yes I exported it, I'm with Neil about
> >Scheme :( )
> >It would probably have only taken someone else 5-10 minutes to fix it.
> >Unfortunately I got too busy to keep plugging away at it and it has now
> >missed the final 1.8 release.
> >
> >I am probably not the only one that could contribute code that way.
> 
> And what stopped you from doing, effectively:
> 
>  cvs -q diff -u | mail gnucash-devel at gnucash.org
> 
> There's nothing that was stopping you from doing this, as far as I can 
> tell.  A
> different SCM would have just changed the commandline you used.

Just because it's *technically* possible doesn't mean there's not a
problem. (It just means there's no technical problem.)  The real
problem is PSYCHOLOGICAL.  Email is final.  For whatever reason, and
for better or worse, our development culture (and most other ones) has
this sense that the diffs sent to a mailing list need to be POLISHED
and CORRECT.  Sharing ONLY correct, polished code is BAD, because most
people need HELP to produce correct, polished code.  Not providing a
convenient way to share UGLY, INCORRECT code is cutting off a large
portion of would-be devs.

> A tool is still a tool.  It doesn't reduce the work involved in writing good
> code.

Actually, good tools *do* reduce the work involved in writing good
code.  Why else would we use them?

> The problem is that historically the commiters have been restricted
> to a trusted group of people, but there are a few "new" developers
> who have not yet been given commit access.  Honestly I can only
> think of one developer in particular.
>
> GnuCash handles people's money!  People need to be able to trust the
> code.  This means limited commit access and gatewaying of patches.

I don't think users trust their data to Gnucash because they know that
"commiters have been restricted to a trusted group of people."
Trusted by whom?  Trusted by the users?  How did they express that
trust in that particular group of people?  Trusted by their duly
appointed representative?  Who, and how were they appointed?  I think
it just doesn't work that way.  I doubt most users know who the
"trusted group of people" are, nor particularly care.

I think users trust their data to Gnucash because the trust the open
source *process*.  They know that anybody can see the code, and they
hope that if there was anything bad in there enough people would see
it to remove it.

To put it personally, they don't care that there's somebody named
<warlord> who made sure those 50 patches didn't get committed until he
committed them himself.  They DO care that there are 100 somebodies
named <whatever> who saw every diff-mail that hit the tree and if
there was something bad, somebody probably would have caught it.

-chris