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

[Chris Shoemaker]

[Neil, I think you accidentally sent this off-list again.  I'm
forwarding it to the list, but just in case it was meant to be
private, I've removed everything except that which I think needs to be
public record.]

On Wednesday 11 January 2006 7:16 pm, you wrote:
> > ? There is no way gnucash can do even 1% of what I want from QOF!!!!
>
> I was only talking about the libqof directory which is presumably 99%
> the same.

It still makes no sense to tie QOF to one particular dependent project. 
Gnotime and pilot-qof have just the same dependency - cashutil will as well 
in due course. Just because gnucash is a bigger codebase doesn't make gnucash 
developers more deserving than gnotime developers.

Bigger isn't always better. GnuCash is getting bloated and it's high time it 
was stripped out, IMHO.

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

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

Consider it a reversed polarity. Originally, QOF was hidden within gnucash. 
Linas and Derek began the process and Linas created a separate library that 
existed LONG before I started with gnucash. I saw a whole new direction for 
QOF that could benefit gnucash but notice how the structure has already 
changed: QOF was the focus, gnucash was the recipient. I began work on QOF 
with gnucash only as a side-effect. My primary goal was to complete Linas' 
work of spinning out QOF into a usable external library and that is now 
complete. My secondary goal was to use that library with pilot-link to 
provide data for gnucash. Again, gnucash is simply a receptacle for the data 
handled by QOF. Recently, I've taken QOF into the embedded arena and it has 
worked well. It could provide a central framework within GPE for all kinds of 
data relationships. This has nothing to do with gnucash and everything to do 
with QOF not caring whether an object is an account or a watermelon.

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

[snip]

> Are you so confident that the best thing _for_QOF_ is to develop in
> practical isolation, where the only eyeballs on developing QOF code
> will be yours, instead of in gnucash's lib/libqof where several other
> developers will see it everyday?

Have you actually read anything I've said? At no point have I said that the 
oversight is unwanted or unnecessary. I just want to be involved PRIOR to the 
commit so that I get a chance to work the changes into my own.

HOWEVER, gnucash's lib/libqof IS JUST A COPY. It is not the active code!

QOF has been external for years, all I've done is let gnucash use it. But then 
you consider that entire effort a complete waste of time and want it 
reversed. Then you say you'd like to help develop QOF? Where to? /dev/null?

> You say that gnucash developers don't have to become QOF developers --
> you'll take care of it.  So is QOF so mature or your skill so great
> that it's better to have one developer in an autonomous repo than
> several developers building _the_SAME_external_library_ from a shared
> repo?

You're talking nonsense and you know it. I have not asked for QOF to be 
autonomous, I merely ask that consideration is given to the life of QOF 
OUTSIDE gnucash.

Stop acting as if I've thrown your teddy out of the pram and get some 
perspective on all this. It is not a big deal, it's just a little sharing. 
Why is that so hard?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




----- End forwarded message -----