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

[Chris Shoemaker]

On Wed, Jan 11, 2006 at 12:58:14PM +0000, Neil Williams wrote:
> On Wednesday 11 January 2006 12:08 pm, Christian Stimming wrote:
> > I'm very sorry and you will probably not like it, but I have to
> > fundamentally disagree about your statement here.
> 
> :-)
> 
> > The code base under lib/libqof/ makes up a fundamentally vital part of
> > the gnucash application, as it includes the fundamental object model,
> > many fundamental data types, the rational number arithmetics, the data
> > file format and parser and similar stuff. In my opinion this makes it
> > necessary that this code base will continue to be double-checked by all
> > gnucash developers
> 
> Sorry if I gave the impression that this oversight was ever to be removed! I 
> agree with you and I've said the same to Derek before. I just want these 
> checks to be complementary, not conflicting. I'm under no illusions about my 
> programming abilities. Equally, oversight / peer review is a fundamental 
> advantage of the entire free software community and it makes absolutely no 
> sense for QOF to go it alone and leave all these advantages behind. I value 
> the input and peer review immensely - I would just like to have more 
> involvement and, dare I say, a little more consideration of my role.

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?

> If there was a way of maintaining this oversight with libqof removed from 
> gnucash I would explore it. 

I don't think that would go over well.

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

> So what I am asking for is merely more cooperation from the other gnucash 
> developers to ensure that external QOF is always available for gnucash. It 
> makes sense at a packaging level to have close cooperation upstream.

I don't think this goal is wise at this point in time.  Indeed, I
think pursuing this goal now _hurts_ gnucash.

[snip]
> > Now you are of course free to develop whatever project with 
> > whatever code you like. But there has never been a discussion of whether
> > the gnucash project will actually accept to have a vital fundamental
> > part of its application to be provided by a separate library that is
> > only under control of you.
> 
> I don't mind the discussion but I think the terms are wrong. I would like a 
> discussion about how gnucash is going to work with QOF as an external library 
> but at no point does it have to be under my sole control.
> 
> 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.

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

[snip]
> Would you consider joining the QOF-devel mailing list (v.v.v.low volume) ?
> https://lists.sourceforge.net/lists/listinfo/qof-devel
>
> I discuss all QOF related stuff there, particularly when a release is close.
> It also includes discussions on all other non-gnucash QOF applications and
> their release schedules.
>
> > The decision to create an "external libqof" was made by yourself (and
> > maybe Linas, but since he isn't active anymore he's not responsible for
> > that right now). Again, you are free to develop yourself whatever you
> > want, and after all this is all GPL, but for the *gnucash application*
> > there are additional levels of trust that have to be fulfilled. In my
> > opinion this level of trust is not (yet?) given for an external libqof.
>
> 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.

[snip] 
>
> All I seek is a little coordination and cooperation.

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.  I'd still love to see commits that migrate
argument handling to C.  It would greatly help coordination and
cooperation if you would develop in small changes in some public
place.  It would also help if you would clarify your intentions for
the cash-util branch.

As for coordination and cooperation on QOF, I'd recommend working
in-tree.  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?

-chris