On Fri, Oct 14, 2005 at 08:51:12PM -0400, Josh Sled wrote: > On Fri, 2005-10-14 at 16:13 -0400, Chris Shoemaker wrote: > > Yeah, who knows what those numbers mean. But, there's a very > > noticable difference between a project that has a healthy development > > rate - even in maintenance mode - and one that doesn't. And we don't. > > That is very true. > > > > I agree that all those things are good goals, but how do we get there? > > There's a chicken-and-egg problem here. All that "clean > > up/simplification" does reduce pain and it does feedback into more > > developers, but it takes work, which takes the developer time we don't > > have. > > True. It is also fun to some large degree, as well as enlightening. > > > > I guess that's the key of what I'm saying: I don't believe that making > > codebase simplification the #1 priority will achieve codebase > > simplification. However, making "something else" the #1 priority > > *will* achieve codebase simplification incidentally. > > Certainly we could set "simplicity" as a goal and either succeed or fail > at it.
Yes, I'm saying we would fail, because "simplicity" is not a sufficiently motivating goal. > But it's not clear to me that setting a different goal will > necessarily incidentally make us achieve "simplicity". Well, that's the heart of my assertion: Trying to remove the pain will result in reduced complexity; Trying to reduce complexity will result in very little because there's too much pain. > > FWIW, my goal in working with gnucash isn't 'fun', as such. It's > primarily experience and knowledge. If I want fun, there's better > places and projects for that, and I do them on the side. You've hit the nail on the head. This is *exactly* why you're still around and so many other people are not. The problem is: there aren't enough people like you to sustain the project, and there never will be. > But my goals > for gnucash are simplicity, stability and correctness. I'd rather > gnucash be in the 200-year-software school [1] than the > 200-active-contributors school. One way or another, if we don't get more developers, in about 200 *weeks* we're not even going to have 200 users. There is *no way* GC is even close to mature enough to be thinking in these timeframes. A year ago I would have said that the key to getting more developers was codebase simplification. Today, I think that codebase simplification is one part of a goal that we can only achieve indirectly through the goal of development process improvement. -chris <snip> > > [1] http://www.bricklin.com/200yearsoftware.htm > > > > > We've been > > > talking about switching over to svn on irc... > > > > Who's "we" and how serious are "we"? I'd be game for trying out > > whatever, but I was more intrigued by git and mercurial. > > hampton, warlord and myself. Serious, as we've all independently been > happy using subversion in other contexts. It won't take too long, but > it too seems best waiting until g2 is out of the way. > > > > > ... but *NOTHING* else is as important, right now, as the G2 port and > > > next/first release thereof. > > > > This must be some of that pressure Neil mentioned. :) It sure will > > feel nice to finally say "proudly presenting, the long-awaited....." :) > > Yeah, and true. We really need to get a release out for a variety of > reasons, and then focus on some actually-fun work doing some major > cleanups. But all that stuff is necessarily destabilizing, so it > doesn't seem like a good idea to do it right now. Yes, right now, code cleanup is destabilizing. But, development process improvements don't necessarily change code. Furthermore, with an improved process, the code cleanup wouldn't have to be destabilizing. Case in point: If we had better version control, I think there wouldn't have been any conflict between qof-work and g2 work, because they would have naturally fallen into different branches. Right now, for all intents and purposes we might as well not even know what branching is. After all, we're basically all on one branch. -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
