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

Neil Williams linux at codehelp.co.uk
Wed Jan 11 07:58:14 EST 2006


On Wednesday 11 January 2006 12:08 pm, Christian Stimming wrote:
> 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

Sorry if I gave the impression that this oversight was ever to be removed! I 
agree with you and I've said the same to Derek before. I just want these 
checks to be complementary, not conflicting. I'm under no illusions about my 
programming abilities. Equally, oversight / peer review is a fundamental 
advantage of the entire free software community and it makes absolutely no 
sense for QOF to go it alone and leave all these advantages behind. I value 
the input and peer review immensely - I would just like to have more 
involvement and, dare I say, a little more consideration of my role.

If there was a way of maintaining this oversight with libqof removed from 
gnucash I would explore it. Short of adding each of you to the QOF project at 
SF and making more work for everyone, I don't see a way. The use of svn and 
cvs makes it difficult (impossible?) to combine the two trees automatically.

So what I am asking for is merely more cooperation from the other gnucash 
developers to ensure that external QOF is always available for gnucash. It 
makes sense at a packaging level to have close cooperation upstream.

> , 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.

Each time that happens, you sacrifice external QOF support. It doesn't need to 
be that way.

> The "external libqof" project, on the other hand, is developed solely by
> yourself.

It doesn't have to stay that way. True, I have non-gnucash tasks for QOF that 
require code that gnucash may not want to use but there are also other 
developments within external QOF that gnucash will certainly want to use. 
Some are being developed within gnucash code using the cashutil branch.

Some uses of QOF will deliberately compile it so that gnucash cannot use it 
(i.e. on embedded systems where gnucash couldn't run anyway.) On platforms 
that *can* run gnucash, external QOF will always support gnucash, and gnotime 
and pilot-qof and a few others that I have planned.

QOF has always had aspirations beyond it's life in gnucash, otherwise it would 
not have been spun out.

> 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.

I don't mind the discussion but I think the terms are wrong. I would like a 
discussion about how gnucash is going to work with QOF as an external library 
but at no point does it have to be under my sole control.

It might not be worth making others part of the QOF external project, unless 
anyone would like this to be done. What we need is cooperation so that 
external QOF is always supported by gnucash. I would much rather have future 
gnucash releases as all dependent on external QOF. It makes far more sense to 
reduce the code duplication. To do this, I just need a little help from all 
of you to let me know when changes are needed in libqof.

> 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.

Perfectly reasonable. You can't compile gnucash without QOF, you can without 
OFX.

> 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.

Again, perfectly reasonable.

Changes to libqof by gnucash developers ARE welcome - I would just like more 
coordination.

> 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.

Would you agree to at least work with me on libqof changes? i.e. prior to the 
commit?

> 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.

Now that's what is NOT happening. Improvements in libqof are not being 
discussed with the involved developers - e.g. me. The commits are coming in 
undiscussed and without relevance to release activity in the external QOF 
library. This will come back to bite us if we don't agree on a way of simply 
notifying people about changes that will (or are expected to) affect external 
code.

Packagers should always have the option to use external QOF support for 
gnucash.

Consider gnotime - I don't have write access there, I do maintain external QOF 
support and the gnotime package works perfectly well with external QOF. True, 
it's a tiny application by comparison, but I am intent on maintaining binary 
compatibility throughout libqof1 and on supporting gnucash using external 
QOF.

All I seek is a little coordination and cooperation.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060111/cccf8c18/attachment.bin


More information about the gnucash-devel mailing list