Switching from CVS to Subversion: test svn repo available

[Chris Shoemaker]

On Mon, Oct 24, 2005 at 01:20:11PM -0400, Derek Atkins wrote:
> The problem is that historically the commiters have been restricted
> to a trusted group of people,

I disagree that that's the problem, but, assuming you're
right... How's that strategy been working for GnuCash over the past 3
years?

> 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.

        I suppose you mean me.  You know, I've been devoting quite a
bit of thought to the survivability of Gnucash recently and especially
on attracting new developers.  I'm still mulling over bits, but I have
concluded at least one thing: Giving one more person commit access
WON'T FIX THE PROBLEM.  I'm sure of it.

        I've been trying to answer the question: why aren't there more
developers hacking Gnucash.  Until recently, I found the "codebase
complexity" answer somewhat convincing.

        Interestingly, the installation of gitweb has changed my
perspective of this issue.  (Check it out, it's facinating:
http://www.codesifter.com/cgi-bin/gitweb.cgi)

        What I didn't really appreciate is that there are many more
casual developers submitting patches than I realized.  E.g: Scott
Oonk, Didier Vital, Ed Huff, Frederic Leroy, Dan Widyono, Geert Jan
Jansens, Bill Nottingham, Stephen Evanchik, Paul Kronenwetter, Matthew
Vanecek, Vitaly Lipatov, Heath Martin, Darin Willits, Pritt Laes,
Christian Neumair, Tomas Cernaj, Yves-Eric Martin, Todd Fries, Thomas
Bushnell, David Montenegro, John Ellson, Rich Johnson, James
Strandboge, Phil Longstaff, and many more.

        There are changes from more than 20 people in the recent past,
just for the G2 branch!  These aren't just trivial one-liners, many of
these people are hacking "deep" parts of gnucash, (register, reports,
modules, GUI, etc.) and submitting patches.  But there are some
disturbing patterns.

        For the most part, the contributions don't last very long.
Why?  I can't say it's code complexity, because they've already
grokked the code enough to improve it.  Then why?  I correlated the
patch commits to mailing list entries.  Guess what?  THESE FRINGE
DEVELOPERS ARE PRACTICALLY IGNORED.  Their patches take weeks, months,
or even almost a year to apply, often with no comment or feedback save
perhaps "applied".  This is disrespectful, abusive and, most
importantly, DISFUNCTIONAL.  And it could be one reason why they don't
send more patches.

        It's also clear from the commit and mailing list history that
this problem is getting WORSE with time.  Believe me, giving me commit
access WILL NOT SOLVE THIS PROBLEM.  (Although it would make *my*
development easier.)  

        But, there are solutions, and I'm forming some opinions on
what they might be.  But, I'd REALLY like to hear waht some of these
"fringe" developers think would make them contribute more time and
effort to Gnucash developement.  So, SPEAK UP!!!


> GnuCash handles people's money!  People need to be able to trust the 
> code.  This
> means limited commit access and gatewaying of patches.  

There's something that doesn't sound quite right about this, but I'll
think about it for a while.  

For now, I'll just point out that limited commit access does not
preclude even the most distributed developement model or widest commit
access.  In a fully-distributed model (which I'm not necessarily
advocating) commit access is infinitely restricted.  No one can ever
commit to any repository but their own.  All code-sharing is done by
"pulling" code.  You can be the one-and-only gatekeeper of all patches
to your repository.

Furthermore, even using a centralized SCM, letting new developers use
the SCM doesn't necessarily mean "violating security protocol by
allowing unwashed masses to touch the OneTrueBuild."

> it also means 
> using the
> tools we have appropriately.  Neil should not have been using the g2 branch 
> to
> do the QOF work; there should have been a new branch for that.
> 
> A distributed SCM makes no sense for gnucash.  There just aren't enough
> developers, and the code base just isn't that large.  It's still perfectly
> reasonable to be shipping patches around.
> 
> If you really want a distributed SCM, consider SVK.

I'm looking into it, but it sure doesn't stack up well compared to
other options.  :(

-chris