Should GnuCash use an external QOF library?

Derek Atkins warlord at MIT.EDU
Wed Jan 11 15:38:00 EST 2006


Neil, et al,

Here's a wild idea.  Call me strange, but...

Neil: how would you feel about relocating QOF-CVS to it's own module
on the GnuCash SVN server?  E.g., how would you feel about:

   http://svn.gnucash.org/repo/libqof/trunk/...
                                     /branches/...
                                     /tags/...

This way the gnucash developers can still make changes to libqof, and it
would be easy to merge changes from libqof into gnucash (and back)..
If there are additional libqof devs at SF I could get them an account
on SVN..

Eventually, if you wish, you could migrate back to SF CVS if you really want.

Just a wild idea that might help everyone involved.

-derek

Quoting Martin Preuss <aquamaniac at gmx.de>:

> Hi,
>
> just the opninion of someone standing at the fence, watching :-)
>
> I don't have the insight into Gnucash you guys have, but from here it looks
> like this:
> Some very important internal stuff from Gnucash has become a library of its
> own which is now used by some other applications as well.
>
> Some arguments seem to be about external QOF being only developed by Neil
> while the internal QOF stuff is worked on by multiple very experienced
> developers from Gnucash.
>
> Since there already are other applications using external QOF it is rather
> likely that QOF is being continously developed at Sourceforge anyway,
> regardless of what Gnucash decides.
>
> So the least work seems to be to help Neil in his external QOF and simply use
> that from within Gnucash. Maintaining your own version of QOF seems to be
> more work. However, that would make it necessary for some (if not all)
> Gnucash developers to be members of QOF as well.
>
> It would also make it necessary that important changes to QOF need to be
> discussed before they are made.
>
> I can see why some gnucash developers don't want to subscribe to yet another
> project, but not doing so would make things much more complicated (IMHO).
>
> External QOF has yet another advantage: As far as I heard the release cycles
> of QOF are much shorter than those of gnucash, so bugs in this important
> library can be fixed and made available to the public in much shorter time...
>
>
> Just my 0.02 ¢
> Martin
>
>
> --
> "Things are only impossible until they're not"
>
> AqBanking - http://www.aquamaniac.de/aqbanking/
> LibChipcard - http://www.libchipcard.de/
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available




More information about the gnucash-devel mailing list