Is there anything *enjoyable* about our development process?

[Chris Shoemaker]

On Fri, Oct 14, 2005 at 03:04:06PM -0400, Josh Sled wrote:
> On Fri, 2005-10-14 at 13:53 -0400, Chris Shoemaker wrote:
> > Does anyone agree?
> 
> Mostly.  I'd like to see gnucash (and other projects) *slow down* on
> taking commits because they're good and stable and already does what
> people want.  I also find the commit-counting there to be a bit like
> LOC-counting.

Yeah, who knows what those numbers mean.  But, there's a very
noticable difference between a project that has a healthy development
rate - even in maintenance mode - and one that doesn't.  And we don't.

> 
> 
> > If so, I'd like to start discussing what concrete things we can do to
> > improve the whole developement experience, considering ideas from the
> > article and elsewhere.
> 
> Yeah, certainly.  My list has been:
> 
> - fix the module/library system.
> - get rid of scheme, it's dependencies and the startup loop.
> - reduce complexity
>   - module system, as before
>   - reporting
>   - register
> 
> These all go toward one goal: making the gnucash code small, lean and
> fast.  This leads to more users, which leads to more contributers.  It
> also makes the existing codebase and developers more nimble, as there's
> less to worry about.

I agree that all those things are good goals, but how do we get there?
There's a chicken-and-egg problem here.  All that "clean
up/simplification" does reduce pain and it does feedback into more
developers, but it takes work, which takes the developer time we don't
have.

I guess that's the key of what I'm saying: I don't believe that making
codebase simplification the #1 priority will achieve codebase
simplification.  However, making "something else" the #1 priority
*will* achieve codebase simplification incidentally.

I think that "something else" is "reducing the painfulness of the dev
process", (which does include codebase simplification, but is also
much broader.)

> 
> 
> > E.g. Would a modern version-control system improve the development
> > experience?  (It seems like several of the other recommedations in the
> > article depend on it.)
> 
> I don't see the big win of having a decentralized VC.  

Well, the "decentralized" part may only be important if there are
every more than 5 developers, but the "atomic-changeset" thing I could
see being real useful right now.  Case in point: right now I'd like
mail some patches, but I like smoke-testing the build before mailing.
Smoke-test (open file) fails right now for because of unrelated
changes.  I could probably guess which changes those are, but removing
them from my tree, while keeping all the other stuff, is
... well... way past the threshold of saying "*@#$%, I'll just stop
development until someone else fixes the build, however long that
takes."

> We've been
> talking about switching over to svn on irc...

Who's "we" and how serious are "we"?  I'd be game for trying out
whatever, but I was more intrigued by git and mercurial.

> ... but *NOTHING* else is as important, right now, as the G2 port and
> next/first release thereof.

This must be some of that pressure Neil mentioned.  :) It sure will
feel nice to finally say "proudly presenting, the long-awaited....."  :)

-chris

> 
> ...jsled
> -- 
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`