Should GnuCash use an external QOF library?

[Neil Williams]

On Wednesday 11 January 2006 8:02 pm, Chris Shoemaker wrote:
> 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.

I'll work on that. I use an intranet repository most of the time so that I can 
make sure the code works on other platforms before committing to public CVS.

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

When you find something you want to change in lib/libqof, just let me know. 
Post either directly to me or to QOF-devel. That at least gives me a chance 
to incorporate that into the next release.

I do intend to release libqof often and early - even if the changes are small 
between releases - but no packaged library can be expected to keep up with 
svn. My intention is that libqof is always released well before any gnucash 
release.

If you can just give me an idea that:
a) you plan to make a change in lib/libqof and
b) a rough outline of how you plan to change it

There aren't that many changes in lib/libqof that I can't arrange for each one 
to get into the released library within a month or so, but I do need time to 
check your changes against the other programs depending on libqof. Providing 
nobody makes changes to lib/libqof a few days after a libqof release, that 
is.

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

Just ask, that's all. Let me know - if only to find out when the next release 
is due.

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

If we are reasonable about how often the lib/libqof code really needs to be 
changed, yes. Prior to your change, gnucash needed the original 0.6.0 but 
worked with 0.6.1. I know, I tested it with both. That is my intention, that 
gnucash will continue to depend on libqof1 >= 0.6.0. I am intent on 
maintaining backwards compatibility throughout the life of libqof1. 

If I had had a chance to see your changes, I could have arranged that the 
change was backwards compatible, updating the codebase when it came time to 
copy QOF into lib/libqof prior to a libqof release or maintaining the 
compatibility so that gnucash could once again depend on libqof1 0.6.0 until 
such time as we move gnucash, creaking and groaning, to libqof2.

The only time gnucash needs to move up the increment is if it starts to depend 
on new code added after libqof 0.6.0. That is not necessarily the case with 
each change.

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

I'm concentrating on providing libqof for *releases* of gnucash. I'm sure I 
can cope with those.

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

Because it is completely inappropriate to do so!

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

Stop talking about a fork, I said I do not see the need for a fork. How do you 
interpret that as a fork already having taken place?

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

Build an independent package used by pilot-qof for one. cashutil is already 
enough of a problem in gnucash svn.

> > Absolutely bonkers.
>
> No.  It's not.  Look.  Today's Gnucash from svn WILL NOT WORK with the
> most recently released libqof.

And whose fault is that?

Anyway, as I've said, an external library can support packages but it's 
unreasonable to expect a binary package to keep up with svn until such time 
as a release is made from that svn.

Work with me on lib/libqof changes and we can prevent this happening again:
1) by investigating backwards compatible versions and/or
2) by working with the libqof release cycle instead of against it.

> What are the options? 
>
>   1) Disable --with-qof so no one tries and fails.

No point, you only have to re-enable it prior to release. Besides, I can't 
then test QOF code to be synchronised with svn.

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

What's this obsession with using libqof for svn builds? I'll update the 
release within a reasonable release timeframe. I'll update QOF CVS when it is 
appropriate to do so.

If gnucash developers want to be able to modify lib/libqof between libqof 
releases, then they must be willing to take the penalty that in the meantime 
the build will have to proceed differently.

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

No, it's not. lib/libqof is not being developed. It simply receives a copy of 
the SF code, where the real development takes place, prior to each release 
from the SF codebase.

gnucash svn merely supports the SF development - it receives the copy of the 
SF code to keep gnucash svn updated and provides some oversight of QOF 
development when gnucash is updated.

-- 

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/d64dae44/attachment.bin