Is there anything *enjoyable* about our development process?

Josh Sled jsled at asynchronous.org
Sat Oct 15 11:52:15 EDT 2005


On Fri, 2005-10-14 at 21:05 -0400, Chris Shoemaker wrote: 
> > 4. This isn't gnucash's fault but such a large project is a *difficult* one to 
> > take on. We can't reduce the codebase but I feel we all need to make it 
> > easier for new developers to get "under the hood". One BIG problem for me has 
> > not been "code" but *code management*. Each developer here has their own 
> > scripts and tools, procedures and routines for updating from CVS, test 
> > builds, separate test trees, favourite editors, tab conventions, etc.etc. 
> 
> You're right, this is HUGE.  There's enough pain in the codebase
> itself, but much of the pain is in code management.  We *have* to fix
> this somehow.

I don't think people actually *do* have wildly different ways of doing
these things.  Certainly there's a natural variation in the OS-level
tools and enviornments, but when it comes to how most developers
actually deal with the source, I think it's generally the same.

Apparently the coding-standards document went away, and finding it in
CVS reveals it didn't have a whole lot of info anyways.  It's pretty
obvious from most of the code, but perhaps it's useful to get tab-size
and brace conventions agreed to?


> > Some of this DOES need to be formalised somewhere. I've lost count of the 
> > number of commits where one of the other developers has rounded on me for 
> > some problem that I had not anticipated. We can't all telepathically know how 
> > to manage the code and the commits. Sometimes I do wonder if it is worth the 
> > (seemingly inevitable) hassle. I should not dread making a commit, or have to 
> > set aside most of the following day to answer queries and explain why I did 
> > certain things. 
> 
> Oh man!  This is *exactly* what I'm talking about.  Any enviroment
> that makes you dread and delay committing is pretty much the exact
> polar opposite of the goal set forth in the article.  I have to say, I
> think *this* is the root symptom.  If we can fix this, everything else
> will folow.

Developers *shouldn't* commit code that breaks formatting conventions,
arbitrarily changes existing conventions, has no prior agreement, does
things wildly differently from how anyone else would do it, and needs to
be defended after the fact.  They generally shouldn't commit code that
breaks other people's environments without being very careful, first.
They *should* delay those commits until the commits are ready.  That's
true regardless of how decentralized the build system is, or how widely
the commit-bit is cast, or how much fun is the goal.

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


More information about the gnucash-devel mailing list