Is there anything *enjoyable* about our development process?

[Neil Williams]

On Saturday 15 October 2005 2:05 am, Chris Shoemaker wrote:
> > 1. Hard to follow code layout - src/engine in particular has caused lots
> > of confusion on this list when trying to relate to QOF. CVS is the main
> > problem here, preventing file system re-organisation. (I like CVS but I
> > recognise it's problems too).
> >
> > 2. Confused function naming conventions and file naming conventions.
> > (Again, filename problems are related to CVS - function names are just
> > historical and a lack of time to change them).
>
> I agree w/ 1 & 2, but think of them as the same category of problem.

Yes, I separated them because they have a compound effect on the difficulty of 
understanding the code as a new developer. If one is fixed, the other becomes 
less problematic; with both in place, their effect is greater than the sum of 
the parts.

> > 3. Lack of developers (catch 22 - the fewer active developers, the less
> > time is available to help prospective new developers).
>
> I *strongly* believe we need to stop thinking of this as the problem,
> and start seeing this as just the natural consequence (or symptom) of
> the *real* problem(s).

Yes, that makes sense.

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

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

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.

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

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.

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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051016/8732265e/attachment.bin