[RFC] QOF Policy: sourceforge-qof is forked; no special lib/libqof policy needed anymore

Christian Stimming stimming at tuhh.de
Fri Jul 21 05:59:02 EDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Developers,

now that 2.0 is released, we could pick up and finally close the old
issue from January/February. At the time, the question was whether the
code in gnucash's lib/libqof should be treated any different compared to
any other code in the gnucash SVN.

As for the facts: In the beginning of this year, Neil Williams had
copied changes from the gnucash repository to his QOF project on
http://sourceforge.net/projects/qof and vice versa, so that both trees
contained pretty much the same code. He completely stopped contributing
to the gnucash-SVN repository on April 18th. After some period where
nothing happened, he now continues to work on his sourceforge-qof
project since that date. The CVS is having regular commits by him
http://qof.cvs.sourceforge.net/qof/qof/ChangeLog?view=markup . However,
obviously he doesn't copy any of the gnucash lib/libqof changes into his
project anymore. His changes since then in the sourceforge-qof project
are not at all trivial (and ours in lib/libqof are important as well),
so I think gnucash will not even compile anymore with his QOF code
instead of gnucash's lib/libqof code (although I haven't checked).

In effect, the outcome is precisely what has been mentioned before:
Neil's QOF project is a fork of some part of the gnucash code. The
forking has eventually happened in April this year. His QOF project has
sufficiently diverged so that no direct substitution or merge is
possible anymore.

What does this mean to us? IMHO it means we don't have to treat the
lib/libqof code in our gnucash repository any different compared to the
other gnucash code under src/ (if we ever did). So at this point in time
the answer to the open question from January is: No, the gnucash
developers do not have to refrain from changes in lib/libqof other than
what our normal development process would ask for. Just go ahead and code.

* For example, the hard-coded installation path in the
libqof/qof/qofla-dir.h header which is used only in qof/qofsession.c and
nowhere else could probably be removed and the qofla-dir.h file be
removed altogether. Same for src/engine/gncla-dir.h. Instead, if the
installation path still needs to be specified at compile-time (which in
itself is a bad idea) then this should go into config.h because that's
where compile-time settings should be collected.
* We could even move the whole lib/libqof directory back to src/libqof
at some point in the future to distinguish it clearly from the
goffice/gsf code copy.
* The library itself has already been renamed to libgncqof.la in r14032,
so there is no name collision anymore anyway.

Christian

Derek Atkins schrieb:
> I propose we table this discussion until after 2.0 is released.
> 
> 
> Chris Shoemaker <c.shoemaker at cox.net> writes:
>> Developers,
>>   Here's a proposal.  My understanding is that this proposal for a
>> change of policy will not take effect until it is accepted.
>>
>> Proposal:
>>    GnuCash developers should refrain from making changes (1) to QOF
>> that are visible to users of the QOF API (2). (i.e. changes such that if
>> the QOF code were copied to another program that used a previous
>> verion of QOF code, the behavior of that program might change, or that
>> might require changes to that program in order to preserve old
>> behavior.)
>>
>>
>> Do you agree to this change in policy?  
> [snip]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRMClZmXAi+BfhivFAQInIQQAqD2qD2NYhqbE7KX4Uv40D5fcB9bR/34s
EJQgZMuHa1HLYEEm3njb+sRMjeThQznlG4+rLMw+baoqq89ar3x5W0ERzqj/fFi6
uYMkLV6Ac+pebIbkS/cJtR7JarllonW7NmdOs1iYRD9XAjDqdjL7Ww4qu750HbpN
Icn2/qSPTJ4=
=GoLW
-----END PGP SIGNATURE-----


More information about the gnucash-devel mailing list