Is there anything *enjoyable* about our development process?

[Chris Shoemaker]

On Sun, Oct 16, 2005 at 11:34:24AM +0100, Neil Williams wrote:
<snip> 
> >
> > 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.
> 
> Let's take an example or two and see if I can draw Josh's arguments in line 
> with mine and yours.
> 
> Example 1:
> Currently, the business file backend is broken. /tmp/gnucash.trace confirms 
> this. I have a fix that completely solves the problem. I cannot commit. Why?
> 
> Even though my patch does not affect ANY of the files that have been patched 
> since I last committed, I have to test TWO separate builds. I have to build a 
> pristine copy from CVS prior to putting my changes into that. I also have to 
> build my working copy that now needs to be updated with the latest changes 
> from CVS. This process has currently taken FOUR DAYS due to employment 
> commitments.
> 
> If I could simply commit the change, everyone would benefit.
> 
> Example 2:
> I have a situation similar to yours with patches outside the tree (actually 
> it's a complete tree outside the tree). This tree works with external QOF and 
> I want to be able to commit these changes too.
> 
> Unfortunately, that will require maybe FOUR complete builds going back to make 
> distclean in each case - just because of the negative feedback.
> 
> This is wasting my time, it is delaying others and it is all out of fear.
> 
> Fear is not fun. As a volunteer, fear undermines my motivation to make changes 
> - ANY changes - it erodes the time I have available for working on the code.
> 


> However, the most difficult aspect is that it HIDES my changes from everyone 
> else. Nobody else knows what I am about to change or how it relates to their 
> changes. 

Of all the bad things you listed, all the fear and pain, *this* one
has the worst effect on GC's development.  You'd think there was some
law preventing us from sharing code.  I cannot overstate how
inefficient it is to develop in isolation.  It's worse than having to
build on three platforms before every commit.


> So I have to spend MORE time writing complex emails to the list that 
> try to explain new code that is not itself available for others to inspect.
> 
> A picture is worth a thousand words? A commit is worth 20kb of email 
> description!
> 
> 5 seconds compared to several hours.
> 
> This is ALL because the current version control system relies on the final 
> arbiter being a single directory on a single machine: cvs.gnucash.org.

Unfortunately, you're right.

> 
> I need to be able to make smaller commits that change fewer files in one go, 
> that require less time building pointless trees and which are available for 
> *inspection* by others WITHOUT necessarily having to be IN their build.
> 
> That is a decentralised model - there is no single arbiter, no single source. 
> It's almost like a branch per developer.
> 
> Each branch is folded into the others *when it is ready* but not before. Yet 
> it remains available for others to inspect and use if they want it.

This is key.

> 
> *We should not have to have patches outside the tree!*
> 
> *Breaking the build cannot be allowed to remain a capital offence!*
> 
> We need to ditch the idea that there is a sacrosanct single build. The release 
> is built from those branches that work together. Hiding code in local builds 
> is enforced by the negative feedback and implicit mantras - I thought free 
> software was about sharing code, not hiding it in fear.
> 
> I believe that the current development mantras in gnucash are wrong, not 
> because the *ideals* are wrong but because the implementation forces 
> constraints on those ideals that make the whole process overtly negative.
> 
> "Breaking the build" is only a problem because we have a single build 
> directory on a single server.
> 
> Our bigger problem is that this weakness in our implementation is actively 
> discouraging development, wasting immense amounts of developer time and - 
> fatally - putting developers in fear of change.

I think you're right.  :(

> 
> Why am I prevented from merely fixing the problem?
> 
> Why this emphasis on wasting time building trees over and over and over and 
> over again?
> 
> > 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.
> 
> Code needs to be shared - including broken, in-progress, code. Making changes 
> in gnucash can be a LONG process and an involved, complex task. During that 
> process, it is essential that others can SEE how those changes are 
> progressing.

I couldn't agree more.

> 
> Currently I only have two options to do that:
> 
> 1. Commit and be damned, or
> 
> 2. Waste vast amounts of eeryone's time trying to explain code in emails to 
> the list when it would be far simpler for everyone if they could just look at 
> the code!
> 
> So, generally, I commit and be damned.
> 
> That is actually preferable to spending even more time on a development thread 
> that made a bad assumption at the start.
> 
> I choose to write free software because it CAN be peer-reviewed. Our problem 
> is that our peer review process is crippled, overtly negative, paranoid and 
> prohibits change.
> 
> I am also aware that my own arguments here are working against a change to SVN 
> and a move to something like GNUarch - despite my previous experience with 
> it.

I've been looking at distributed SCMs recently and there seems to be
several options, with Arch not being particularly outstanding in terms
of popularity, features, maturity, friendliness, etc.

-chris