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