Should GnuCash use an external QOF library?

[Chris Shoemaker]

On Wed, Jan 11, 2006 at 06:43:36PM +0000, Neil Williams wrote:
> On Wednesday 11 January 2006 4:23 pm, you wrote:
> >         Should GnuCash use an external QOF library?
> 
> At a packaging level:
> Wherever QOF is available, yes.
> Wherever QOF can be made available, also yes.
> 
> At development level, I'm reasonably happy with a copy of QOF copied into 
> gnucash prior to a QOF release.

I'm not too happy with large chunks of unrelated QOF development being
committed at one shot.  I suppose more frequent syncs would diminish
this problem.  OTOH, I could try to follow the SF CVS commits, but
they don't seem to be very incremental either.

[snip]
> Using QOF externally in development isn't the issue, anyway. Just coordinate 
> with me when you work in lib/libqof.

What _exactly_ does this mean?  I'm reading this as "email me your
patch and wait for an acknowledgement before committing."  Am I close?

> What I ask is:
> 1. Coordinate with me before committing changes to lib/libqof - unless the 
> 	changes are a CRITICAL bug. Even then, let me know *urgently*.
> 2. Always keep in mind that there is as much of QOF outside gnucash as there
> 	ever could be inside and don't make changes that are gnucash-specific.
> 	(i.e. do not use gnucash defined macros or build structures.) This is
> 	imperative in an embedded environment.
> 3. Listen in on QOF-devel just to get notice of latest developments and 
> 	releases.
> 4. Do nothing to increase or modify the existing dependencies of QOF.
> 
> >         I think the disadvantages of Gnucash using external libqof are
> 
> inconsequential at a packaging level.
> 
> > overwhelming, but let's at least ask what are the advantages?  Well, a
> > user who used external libqof for both gnucash and gnotime would save
> > a few kb disk-space.
> 
> QOF is going to be updated far more regularly than gnucash, that's beneficial.

Can you release a libqof _every_ time an API change is made and
increment the corresponding Gnucash "requires qof > x.y.z"?

> > In *theory*, an external libqof would be 
> > maintained by non-gnucash developers, gaining labor efficiency.  But,
> > in practice, allowing external libqof means gnucash-developers have to
> > become libqof developers, with additional overhead labor and _reduced_
> > efficiency.
> 
> ? Nobody from here has to join me in QOF development, I don't see the problem 
> or any additional overhead.

See above.  Your "coordinate with me" sounds pretty much like
additional overhead.

> No gnucash developer needs to be diverted or become a libqof developer. I'll 
> do all that - as long as the gnucash developers respect the division.
> 
> >         1) Continue libqof development in gnucash svn, build and
> > release external stand-alone libraries from this source, even though
> > GnuCash won't use them externally.
> 
> Impossible. libqof cannot be developed in gnucash svn. It has outgrown gnucash 
> and is going into places that gnucash simply cannot follow. Completely 
> inappropriate.

This is hard to believe.  If external QOF builds and it can be synced
to lib/libqof and built for internal purposes, how can libqof not be
built and developed from lib/libqof?

> It's hardly suprising that I've still got some cashutil code outside gnucash 
> svn. I may yet take cashutil to a separate repository - especially as nobody 
> here appears to have even looked at the branch.
> 
> >         2) Fork the code from the gnucash qof, develop and release it
> > independently from Gnucash.
> 
> It is already developed and released independently from gnucash. I don't see 
> the need or benefit for a clean fork, it's just wasting even more effort.

Ok, so you've already forked then.  Please don't complain that people
aren't keeping the code you forked from compatible with your fork.

> Is it really that hard for a free software community to actually SHARE?
> 
> I'm willing to keep gnucash updated with the latest QOF code but I will not 
> make duplicate commits for every single change. Neither can I use gnucash svn 
> for QOF development, it flies in the face of everything I want to do in QOF. 

Huh?  What does it matter where the code is stored?  What can you do
in SF CVS that you can't do in Gnucash SVN?

> The best I can do is update lib/libqof prior to each QOF release.
> 
> > One implication of this is that merges 
> > into gnucash svn's qof should STILL be incremental and reviewable NOT
> > huge "sync with external QOF version blah".  That really bothers me.
> 
> I'm not going to start committing the same change to two trees every time! 
> That's a complete non-starter. No matter how much it may bother you, it ain't 
> going to happen!
> 
> >         In any case, just to make things clear: I'm advocating
> > disabling the option to build Gnucash with external QOF. 
> 
> Absolutely bonkers.

No.  It's not.  Look.  Today's Gnucash from svn WILL NOT WORK with the
most recently released libqof.  What are the options?

  1) Disable --with-qof so no one tries and fails.

  2) Leave it broken.

  3) Release a new QOF ASAP.  Tell people not to use --with-qof until
the new version comes out.

  4) Just tell people to never use --with-qof.

  5) Revert /lib/libqof back to the state after your 0.6.1 release,
along with GnuCash changed that depend on those qof changes.  Stop
development in /lib/libqof and any avoid any improvements to gnucash
that would require changes to /lib/libqof.

You tell me which of those is most bonkers.

> Do you want me to provide a patch that re-enables it for sensible packaging?
> 
> I only ever build gnucash with internal QOF prior to a QOF release.
> 
> > The only 
> > reasonable alternative is to stop development in /lib/libqof when
> > external QOF does a release.  I'm strongly against that alternative.
> 
> There IS NO development in lib/libqof (that's why it's no longer under src/).

Do you realize how that assertion is ...

> 
> QOF development happens at SF, it is discussed via QOF-devel and released 
> early and often. 
> 
> What happens in gnucash svn merely supports the SF development.

... completely incompatible with this one?


-chris