On Fri, Oct 14, 2005 at 03:04:06PM -0400, Josh Sled wrote: > On Fri, 2005-10-14 at 13:53 -0400, Chris Shoemaker wrote: > > Does anyone agree? > > Mostly. I'd like to see gnucash (and other projects) *slow down* on > taking commits because they're good and stable and already does what > people want. I also find the commit-counting there to be a bit like > LOC-counting.
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. > > > > If so, I'd like to start discussing what concrete things we can do to > > improve the whole developement experience, considering ideas from the > > article and elsewhere. > > Yeah, certainly. My list has been: > > - fix the module/library system. > - get rid of scheme, it's dependencies and the startup loop. > - reduce complexity > - module system, as before > - reporting > - register > > These all go toward one goal: making the gnucash code small, lean and > fast. This leads to more users, which leads to more contributers. It > also makes the existing codebase and developers more nimble, as there's > less to worry about. 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. 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. I think that "something else" is "reducing the painfulness of the dev process", (which does include codebase simplification, but is also much broader.) > > > > E.g. Would a modern version-control system improve the development > > experience? (It seems like several of the other recommedations in the > > article depend on it.) > > I don't see the big win of having a decentralized VC. Well, the "decentralized" part may only be important if there are every more than 5 developers, but the "atomic-changeset" thing I could see being real useful right now. Case in point: right now I'd like mail some patches, but I like smoke-testing the build before mailing. Smoke-test (open file) fails right now for because of unrelated changes. I could probably guess which changes those are, but removing them from my tree, while keeping all the other stuff, is ... well... way past the threshold of saying "[EMAIL PROTECTED], I'll just stop development until someone else fixes the build, however long that takes." > 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. > ... 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....." :) -chris > > ...jsled > -- > http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL > PROTECTED] _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
