[c.shoemaker@cox.net: Re: QOF is external, please tell me if you plan changes within]

[Chris Shoemaker]

[oops, reply meant for list, too]
On Wed, Jan 11, 2006 at 05:56:19PM +0000, Neil Williams wrote:
> On Wednesday 11 January 2006 5:25 pm, you wrote:
> >
> > 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!!!!

I was only talking about the libqof directory which is presumably 99%
the same.

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

I don't think it's quite the same.

> 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.  Have any gnucash developers (other than yourself) done so?  

Simply moving files from src/engine to lib/libqof doesn't make it so.
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.

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

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.  Why does he make it so hard for himself?  and for me?  Now I
have to check that the fix isn't undone next time he commits mongo
'Sync with QOF 0.x.x' change.  And now I have to worry about some
misguided user who Neil's told to build gnucash with external libqof,
who won't have this change because the last libqof release was X
months ago.  Gnucash probably won't build for him until he drops the
stupid --with-qof.  Or I could just leave the stupid bug and go have a
beer.  Hmm..."  My next action depends on my mood at the moment.  But
I know the _right_ response for GnuCash: screw --with-qof!

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

Umm... 53 messages over 8 months, 3 subscribers, and 28 CVS commits.
I really don't think I'd mind the traffic 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.

You see, infrequent huge commits for *cashutil* doesn't really help
*Gnucash* very much, but if that's what you've got, I guess that's
what I'll use.

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

No, Neil.  *Incremental Improvement* I'm really serious about this.
Really.  Cashutil and some QOF at SF can be developed however you
please, but small projects can withstand radical unitary changes can
_kill_ complex projects like gnucash.

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

a) I also mean QOF development.
b) Since you aren't intending branches/cashutil for a merge into trunk
it's a bit difficult to incorporate meaningful changes.

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

Well, we obviously disagree here, but let me make a pragmatic argument:

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?

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?

-chris

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