Switching from CVS to Subversion: test svn repo available

Tue Oct 25 06:16:51 EDT 2005

On Tuesday 25 October 2005 3:26 am, Chris Shoemaker wrote:
> On Mon, Oct 24, 2005 at 09:37:07PM -0400, David Hampton wrote:
> > > I've spent more time refreshing out-of-tree patches that I have
> > > actually developing code! (ok, not really, but a LOT of time, it's a
> > > PITA.)
> >
> > You should have spoken up the moment you saw Neil's patches go in and
> > said to yourself "that's not related to the gtk2 port."
>
> To be fair, I didn't *know* they weren't related to G2.  I guess
> that's my ignorance but I'm not sure why noticing that should be /my/
> sole responsibility.

If I'd known early on that Chris' patches existed out of tree and that they 
involved areas I wanted to redesign, I would have tried to help and weave the 
two together. I've stayed out of this discussion because I only have limited 
knowledge of CVS (and live with it) and GNU arch (bad experience due to 
inexplicable config). I don't feel qualified to discuss the details of one 
tool over another.

What I would like is independent of the tool(s) we use:

1. Occasional developers - those committing patches once in a while like 
Didier - to have an easier method than posting patches to a mailing list. 
Maybe a "new developer" branch. After all, that is how nearly all the current 
developers started.

2. More emphasis on why and how branches should be used and guidelines for new 
developers on code management. Some method of clearly attributing branches to 
particular goals beyond a short, cryptic, branch name.

3. More acceptance that new developers don't necessarily know the unwritten 
conventions of code management in GnuCash. Encourage such developers to use 
personal branches so that everyone can see what is being done BEFORE it gets 
into HEAD or other "critical" branches like gnucash-gnome2-dev. (This 
naturally involves making such branches easier to manage for everyone.) 
Recently, we've had numerous people interested in building gnucash and 
numerous posts of the -devel list covering basics like which branch to use 
and how to check it out. Clearly, our documentation needs improving - it 
appears to be pitched at a level of background knowledge that is higher than 
the people being attracted to development.

4. Has anyone seriously considered using the SourceForge project more? SF is 
sticking with CVS but we don't have to use it. Other projects successfully 
use the SF Trackers for patches and the SF documentation is much better than 
our own. Currently, no SF trackers are available. SF Tasks could also help by 
making out-of-tree work visible to everyone. Again, not enabled. Ideally, 
everyone with commit access should have membership of the SF project and be 
able to at least update the trackers, tasks and documentation.

5. More write access to online information outside the mailing list archives. 
The gnucash.org website is not being updated, new documentation has to go on 
other websites and isn't always linked from the gnucash site. At least if we 
used SF more, all listed developers could correct, update and submit 
documentation on *code management* issues. Using News and/or Docs on SF could 
dramatically increase the ease of drafting new developers into the fold.

Overall, I don't care which tool everyone else decides to use, all I want is 
more publication. More code, more visible and less reliance on the CoreBuild. 
This is free software, it's meant to be shared around - yet the current 
system discourages sharing ideas and code plans, insisting on completed code 
that doesn't break the CoreBuild. All this does is virtually guarantee that 
new code will be incompatible with someone else's out-of-tree code, contain 
entrenched ideas that are hard to fix at such a late stage and lower the 
overall code quality. We need more peer review of incoming code and that can 
only come from more publication, more sharing, of the code itself at the 
earliest possible stages.

Why don't we use SF more? We don't even promote GnuCash as an SF project. We 
use the file release mirrors and the donation system and that's about it.

Maybe I joined too late to know why SF was left as a stump but I find it very 
useful and I think it can still help with our current problems.

> > > It's pretty off-putting.  I think, ideally, *anyone* who wants
> > > to should be on the SCM train.  Let everybody go as fast as we know
> > > how.  If people think it's best to require some test of endurance in
> > > order to write to the OneTrueBuild, then so be it.
> >
> > Its not an endurance test.  I for one want to see the quality of code
> > that people write before I give them free reign to play in the "One True
> > Build".

Which is why, IMHO, we need more publication of code. "out-of-tree" code 
should be banished. All code related to gnucash present or future should be 
visible to all developers, no matter what state it is in. I desperately want 
people to have a chance to see cashutil, even in it's current state.

Small snippets of code could go on SF Trackers.

Large chunks like Chris' "out-of-tree" code and cashutil should be visible to 
everyone via whatever WWW tool we use for viewing the development code. I 
don't much care how, as long as it is EASY (to create and merge), quick to 
update (i.e. not moderated), separated from the CleanBuild/CoreBuild and well 
documented.

If nothing else, I want all gnucash code in all stages to be visible to all 
developers - new and old.

> > I agree with you there.  Code should stand on its own, but I insist on
> > knowing that its quality code.  I'd rather take the time to look at a
> > new developer's patches up front than to have the program blow up in
> > strange and mysterious ways, and then have to track down problems after
> > the fact.

And I wish I'd known how to achieve that when I started with gnucash. I 
didn't, I started in HEAD, I moved to gnucash-gnome2-dev only because of 
libxml2 dependencies and it was only when I had completed 95% of my redesign 
that anyone suggested a branch of my own. I wouldn't have minded using a 
branch if someone had suggested it this time last year (and explained the 
benefits). It's one of those things that new developers cannot be expected to 
know in advance. Some may feel that this can and should be expected - all I 
can say is this kind of elitism will only further weaken the appeal of 
gnucash development.

If we had online development documentation that could be updated by any 
member, I believe things would be far simpler for people like me. I know we 
have the Wiki but that is more of a users site - where development can be 
explained to curious users.

> > > > and old devs leave as they find other projects to work on.  The main
> > > > issue is that ALL the core devs got burned out after 1.8 and there
> > > > weren't any fringe devs to pull up in the ranks.

Volunteers will get burned out if the "code management" conventions are not 
explained and updated.

> > Define healthy dev rate.  In the four years that I've been associated
> > with the project its never had more than a handful of core developers.

I still believe that this is a weakness, not a validation. Volunteers we are 
and volunteers we are likely to remain - motivation is imperative and 
anything that saps that motivation must be our collective enemy.

The current "code management" fog has seriously drained my motivation for 
gnucash development. It's only since I made my most recent commit here and 
was able to move back to QOF that I have rediscovered the pleasure of 
programming. In QOF, I can relax and write better code. I commit much more 
frequently and in smaller chunks. The only reason for this is that I am not 
afraid of committing. I should not fear a gnucash commit and although this 
has improved recently, it's a hard memory to shift.

Developing in gnucash MUST be fun, it must be enjoyable and give a feeling of 
reward. Personally, I do not believe this will be possible until all work is 
within the tree and this paranoia about the CoreBuild is salved by having 
easier branches and MUCH better documentation of the implicit conventions.

> > None of the core developers are still around from when I started working
> > with Gnucash, except for Derek.  I've gone from guy submitting patches
> > to the build system to primary developer.  Josh started sometime after
> > me and wrote the entire scheduled transaction system.  Neil's come in
> > and redesigned a core part of the engine.  We have the same number of
> > core devs as in 2002, just different ones.

And how long before this collection of over-worked developers burns out?

I'm not the only one feeling that gnucash development is unnecessarily 
burdensome. The contrast with my other projects is all too clear. There is a 
limit - a point beyond which it would be too much effort to continue and that 
point is always closer than it may appear in voluntary projects.

I've worked in voluntary projects of other kinds, I've worked with charities 
and setup my own charity from scratch - I know the personal pain of burn out 
and I feel I know the signs.

-- 

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/20051025/4c5cef63/attachment-0001.bin