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

[Neil Williams]

On Wednesday 11 January 2006 5:25 pm, you wrote:

(sorry, meant for the list.)

> I don't think there's a lack of consideration.  I think it's just a
> disagreement about your role.  I view your role as a general gnucash
> developer who happens to also be involved in packaging/maintaining an
> external libqof.  I think _you_ view your role as developing Gnucash
> to allow it to use an external libqof.  The real issue is technical,
> not social, isn't it?

I am a QOF developer first and foremost. In order to achieve what I want from 
QOF, I needed to complete the spin out. One (but only one) part of my QOF 
work is to use QOF to automate the generation of gnucash invoices from Palm 
data. This continues to require work within gnucash. Another QOF role is 
cashutil. Recently, most of my effort has been on another QOF project, 
pilot-qof which has now been backported to pilot-link 0.11.8 because 0.12 is 
so delayed.

> > Short of adding each of you to the QOF project at
> > SF and making more work for everyone, I don't see a way. The use of svn
> > and cvs makes it difficult (impossible?) to combine the two trees
> > automatically.
>
> This is a self-imposed trial.  It's _much_ easier to make one tree do
> two different things, than it is to sync two trees each doing
> something different with the same code.

? There is no way gnucash can do even 1% of what I want from QOF!!!!

Where QOF is going, gnucash cannot follow.
(apologies to Tom Clancy.)

> > It might not be worth making others part of the QOF external project,
> > unless anyone would like this to be done. What we need is cooperation so
> > that external QOF is always supported by gnucash. I would much rather
> > have future gnucash releases as all dependent on external QOF. It makes
> > far more sense to reduce the code duplication.
>
> Using the code internally and also building external libraries from
> the same code is not duplication.  Ironically, _you've_ greatly
> increased code duplication by maintaining a new copy of QOF outside of
> Gnucash svn, where it still lives.

No. Only a COPY of QOF survives in svn. It's the same as goffice.

All QOF development happens at SF.

> >To do this, I just need a little help from all
> > of you to let me know when changes are needed in libqof.
>
> When I commit a change to /lib/libqof/ it's because I think a change
> is needed.

Without any consideration of me, presumably.
:-(

> > I don't have commit logs sent to a mailing list for QOF (yet),
> > principally because it is only me. I think SF can do that if anyone is
> > interested. I would welcome any gnucash developers to join me in QOF
> > development but I don't expect many to have the time. So I'd rather keep
> > discussion here - just\ have a little more in relation to changes in
> > libqof.
>
> This is just weird.  You want us to join some obscure ML where you
> have some QOF discussions but you also want to keep QOF discussions
> here because of the relation to the code.  Just keep discussion and
> development in the same place: here.

You really don't want me discussing pilot-qof, qof-generator and gnotime here, 
let alone my embedded QOF work. QOF-devel is the place for all that stuff.

QOF cannot develop within gnucash.

Mainstream QOF development and qof-related tools on QOF-devel. GnuCash related 
QOF discussions here.

> Me too.  I've been avoiding the argument handling stuff for Gnucash
> because I was waiting for you to respond to my question on Jan 3 if
> you were going to do it.

See the cashutil branch. I have had other priorities in the meantime. There is 
a gnucash2 binary build in cashutil svn that supports popt options. I just 
need a little more work to get the gnucash main window to open.

> I'd still love to see commits that migrate 
> argument handling to C.

Then work with me on the cashutil branch where the code is relatively 
advanced, albeit incomplete.

> It would greatly help coordination and 
> cooperation if you would develop in small changes in some public
> place.

branches/cashutil

> As for coordination and cooperation on QOF, I'd recommend working
> in-tree.

Nope. QOF is developed at SourceForge. gnucash svn just gets a copy prior to 
release and after testing the release in gnucash. It is completely 
inappropriate for QOF to be developed at gnucash svn.

> You can't substitute for proximity.  I'm personally 
> volunteering to help improve libqof.  If you handle the build
> infrastructure for making an external library from Gnucash svn's
> /lib/libqof/, then we can work together on incrementally improving the
> actual code.
>
> What do you think?

Future direction of QOF has very little to do with gnucash. It's simply wrong 
to put the two together.

-- 

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