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/
pgpZvHZJbVNkW.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
