First, a little Hello,
I'm Adrian Simmons and I've been subscribed to gnucash-user for some time, but
decided I'd come and lurk here for a while, and though I'm only a web geek at
least see if I can help out somewhere. I run Gnucash on OS X via Fink.
Chris Shoemaker wrote:
Giving one more person commit access
WON'T FIX THE PROBLEM.
The open source project I've been most involved in is Drupal, the web CMS, and
this really strikes a cord - every few months someone suggests that Drupal-core
needs more than it's current three committers. You're right, it really won't help.
Their patches take weeks, months,
or even almost a year to apply, often with no comment or feedback save
perhaps "applied".
<snip>
It's also clear from the commit and mailing list history that
this problem is getting WORSE with time.
I'd suggest that something more formal than a mailing list might help. Take a
look at Drupal's patch queue:
http://drupal.org/project/issues?projects=3060&states=8,13,14
This provides a central place for people to provide patches, comment on them,
improve them, receive feedback etc. Until a patch is rejected the code never
gets lost, and the contribution is visible. Contributers can monitor the
progress of their patch, and have a URL to point to when advocating it. Would
something like this help Gnucash?
(I'm speaking as someone unaware of how Gnucash devel currently proceeds here,
so I may be off the mark..) There is a secondary element here though, it's not
enough just to submit patches, usually a project will need more than the core
commiters to review patches. If 'fringe' developers also review other developers
patches it will help the core developers decide which patches to apply, and
should speed progress though the queue. Admittedly reviewing patches is a lot
less exciting than writing new code, but it has to be done and it's better if
everybody joins in.
I think a web based patch queue would help with that too.
I'm not suggesting it would have to be based on Drupal. There may well be better
options.
GnuCash handles people's money! People need to be able to trust the
code. This
means limited commit access and gatewaying of patches.
I'd support that, a limited set of core commiters can help to ensure code
quality and a solid overall architecture of the product. There is always going
to be a tension between the latter and the rapid addition of new features.
If you really want a distributed SCM, consider SVK.
One of the plus factors of switching from CVS to SVN is that it's not all that
different at the level of the command line. It's pretty easy to make the switch,
not a lot of new commands or syntax to learn. And debates about SCM philosophy
aside, SVN *is* better than CVS. Sometimes little steps are better than giant leaps.
--
adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com>
e-mail <mailto:[EMAIL PROTECTED]>
AOL/Yahoo IM: perlucida, Microsoft: [EMAIL PROTECTED]
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
