QOF is external, please tell me if you plan changes within

Christian Stimming stimming at tuhh.de
Wed Jan 11 07:08:24 EST 2006


Dear Neil,

I'm very sorry and you will probably not like it, but I have to
fundamentally disagree about your statement here.

The code base under lib/libqof/ makes up a fundamentally vital part of
the gnucash application, as it includes the fundamental object model,
many fundamental data types, the rational number arithmetics, the data
file format and parser and similar stuff. In my opinion this makes it
necessary that this code base will continue to be double-checked by all
gnucash developers, including the possibility to submit our changes
ourselves. I do consider it necessary that this code will continue to be
"a part of" gnucash and will remain under the control of the gnucash
developers.

The "external libqof" project, on the other hand, is developed solely by
yourself. Now you are of course free to develop whatever project with
whatever code you like. But there has never been a discussion of whether
the gnucash project will actually accept to have a vital fundamental
part of its application to be provided by a separate library that is
only under control of you. Because if we started that discussion, then
the answer at least from myself will be a clear "no" (sorry for that).

I think your code quality is nice and still improving, but in my opinion
your code quality is not at a level where the gnucash project can trust
it without also having the control over it. I wouldn't care if this
discussion were about a sub-module that is only needed for special
actions (like libofx for the OFX importer), but I *do* care for *this
vital part* of the application. Instead, I think the appropriate level
of mutual trust is the current status: You, as well as (how many
actually? I think 5-7) 6 others, have write access to the same SVN, and
every change of each of us can and will be double-checked by others. On
that level of trust and mutual control I'm totally convinced that your
contributions are a good improvement for the overall project and they
are always very welcome. However, that level of trust and mutual control
does not hold any longer for your external libqof code. In that project
you are the only active developer -- no doubt you would gladly accept
more developers, but I for one don't want to join yet another project
but instead want to develop the gnucash-relevant code inside gnucash.

The decision to create an "external libqof" was made by yourself (and
maybe Linas, but since he isn't active anymore he's not responsible for
that right now). Again, you are free to develop yourself whatever you
want, and after all this is all GPL, but for the *gnucash application*
there are additional levels of trust that have to be fulfilled. In my
opinion this level of trust is not (yet?) given for an external libqof.
That is why I *do* consider the lib/libqof code base to still be an
integral part of gnucash. I do *not* agree to treat it as an external
library. I *do* encourage every gnucash developer to treat it exactly as
we would treat every other part of the gnucash codebase: Fix bugs
everywhere, discuss improvements with the involved developers. That is
exactly what Chris has done, and that is what I want to encourage
everyone to continue to do.

Best regards,

Christian

Neil Williams schrieb:
> Chris, would you mind letting me know which QOF files you are working on and 
> letting me see your libqof changes in advance?
> 
> I'd much rather have changes in external QOF copied into gnucash for use 
> internally.
> 
> I've only just released QOF 0.6.1 and if you had said you had changes for 
> libqof, I could have incorporated them. Revision r12299.
> 
> I've asked before, but can we *please* work together because your changes are 
> overlapping my changes, both in libqof and in the replacement of scheme in 
> the load mechanism.
> 
> libqof is now external and should be treated as such. Unless there is a 
> critical bug in libqof/*, PLEASE can everyone at least let me see the change 
> before you commit and just let me know what you are planning within libqof/*.
> 
> libqof should no longer be seen as 'owned by' or 'only a part of' gnucash.





More information about the gnucash-devel mailing list