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

[Chris Shoemaker]

On Wed, Jan 11, 2006 at 08:09:05PM +0000, Neil Williams wrote:
[snip]
> > > All QOF development happens at SF.
> >
> > You're implying that the gnucash developers have agreed to stop
> > development of the in-tree QOF and develop QOF only in your fork at
> > SF. 
> 
> It's not a fork. QOF lives at SF. It no longer lives inside gnucash, that's 
> just a shell, a copy, a mirror.
> 
> > Simply moving files from src/engine to lib/libqof doesn't make it so.
> 
> It should at least give you a hint that there is something different about 
> those files. They are NOT gnucash specific. They need special attention to 
> retain their independence. I am absolutely committed to that.

  It's a hint that there is some future intention for gnucash to use
QOF as an external library.

> 
> > I certainly didn't view that move as a restriction on further in-tree
> > development of QOF.  I thought it was basically a convenience for you
> > in order to build stand-alone libqof.
> 
> No, it was a spin-out, just as I said at the time. Spinning QOF out of 
> gnucash. It was about a relocation of control. A shift in focus.

  Did _any_ gnucash developer besides yourself agree to this
relocation of control at that point, with QOF and gnucash in
their respective states?  No.  Would they have if you had asked?
Probably not, but I don't speak for anyone other than myself, so why
don't you ask them?

  Yet you still believe that gnucash developers should stop
development in /lib/libqof.  Why have none of the active gnucash
developers become SF QOF developers?  Do they not care about QOF
anymore?  Are they all relieved to have finally offloaded maintenance
of that troublesome chunk of code?  I think not.  Perhaps they don't
know that they're no longer in "control" of lib/libqof.

> > To be honest, there is consideration. It goes:
> >
> > "Oh. Here's another nitfol that needs to be fixed.  There.  That's
> > better.  Oh darn!  It's in libqof.  That means more work for Neil who
> > presumably wants to pull the fixed-up nitfol into his external CVS
> > repo. 
> 
> Yes. Providing it fits with the true purpose of QOF, outside gnucash. 
> Otherwise, I WILL reverse the change when release time comes.
> 
> > Now I  
> > have to check that the fix isn't undone next time he commits mongo
> > 'Sync with QOF 0.x.x' change.
> 
> No. I'll do that, as long as you let me know about the change. Currently, I 
> have to do that afterwards and maybe fix the patch to work outside gnucash, 
> recommitting the corrected patch to gnucash svn when QOF is ready for 
> release. All I want is for this to be done BEFORE you commit.
> 
> Why is it so hard for you to just involve me in it?

You don't want "involvement".  You want "relocation of control" and
you "WILL reverse" changes that you feel don't "fit with the true
purpose of QOF."  You want too much.

[snip stuff I didn't forward.]

Clearly, you are only considering support for "released" versions of
Gnucash.

If that's a your major concern, how about this proposal:

  We'll disable building with external QOF in gnucash svn.  Gnucash
developers will continue developing QOF as they always have, in
Gnucash svn.  Any change to lib/libqof you can see immediately and
change if you like, and/or pull to external if you like.  The Gnucash
release process will be well-advertised and some period before release
we'll agree not to change lib/libqof, so you'll have plenty of time to
pull any remaining changes and test Gnucash with external qof.  We'll
re-enable an optional external QOF before release.  That way, Gnucash
can still use external QOF.  Does that sound agreeable?

[snip]


-chris