[RFC] QOF Policy: sourceforge-qof is forked; no special lib/libqof policy needed anymore

[Derek Atkins]

A few of us discussed this on IRC today.  The executive summary:

* QOF has forked and we can/should just ignore what happens in
  QOF-CVS.  Indeed, we might even just want to move lib/libqof/qof ->
  src/qof in our source tree to make it more clear.
* We should keep goffice/libgsf as long as it's cheap to do so.
* We should keep glib/gtk 2.4 support as long as it is cheap to do so.

-derek

<cstim> Neil's qof-devel list has one posting per week: http://sourceforge.net/mailarchive/message.php?msg_id=29456298 explaining his work on the qof-date data type.
<warlord> I think we can just ignore it.
<cstim> sure.
<cstim> I guess this is also your conclusion to the "qof-policy" final question?
<warlord> yeah.  i think it's just a fork and we can just ignorehis work.
<cstim> yeah.
<warlord> We could move it from lib/libqof/qof to src/qof
<warlord> and just reclaim it as our own.
<cstim> I would totally agree to the svn move.
* jsled agrees.
<warlord> I also think we can remove libgsf and goffice from our tree in trunk and just assume that distros will provide it.
<warlord> (i think we can also remove the glib-2.4 compatibility in trunk)
<jsled> yeah.  Did we want to do that for 2.2 or 3.0.
<jsled> ?
* cstim still uses gnucash's copy of gsf,goffice...
<warlord> Okay, we can rip it out for 3.0
<cstim> but my suse9.3 is probably old enough.
<jsled> I mean, there's very little cost to trying to retain 2.4/gsf/goffice support for the upcoming release.
<jsled> (2.2, I mean)
<warlord> Hey, I wont complain about keeping the support!
<jsled> heh.
<cstim> That's the point. As long as the support is still cheap for us, we can simply keep it.
<warlord> people wanted to rip it out prior to 2.0, so...
<cstim> At least one strong argument against that dependency night..something issue :-)
<warlord> i'm just saying that I have no problem removing it.  But I agree with cstim -- if it's cheap to keep the support then we should.
<jsled> yup.
<jsled> I have a feeling the gtk/glib compat layer is going to be the first thing to go.
<cstim> warlord: btw have you met benoitg?
<warlord> Yep!
<cstim> did you ask him to kindly have a new libofx release :-)
<warlord> yes, I did.
<cstim> thanks a lot.
<cstim> err, what was the answer?
<jsled> So, who's going to re-iterate the above bits to -devel for the record?
<warlord> his answer was that he's got a few changes he still wants to make.  But he said he was going to get to it.
<warlord> jsled: about qof?  I'll cut-and-paste this conversation in reply to the list.  ;)
<cstim> re libofx: oh yes, there's some bugfixing activity in http://libofx.cvs.sourceforge.net/libofx/libofx/ . Very good.
<jsled> Well, the QOF bits and the lib/{gsf,goffice} and g* compat policy.
<cstim> ok, see ya

Christian Stimming <stimming at tuhh.de> writes:

> Developers,
>
> now that 2.0 is released, we could pick up and finally close the old
> issue from January/February. At the time, the question was whether the
> code in gnucash's lib/libqof should be treated any different compared to
> any other code in the gnucash SVN.
>
> As for the facts: In the beginning of this year, Neil Williams had
> copied changes from the gnucash repository to his QOF project on
> http://sourceforge.net/projects/qof and vice versa, so that both trees
> contained pretty much the same code. He completely stopped contributing
> to the gnucash-SVN repository on April 18th. After some period where
> nothing happened, he now continues to work on his sourceforge-qof
> project since that date. The CVS is having regular commits by him
> http://qof.cvs.sourceforge.net/qof/qof/ChangeLog?view=markup . However,
> obviously he doesn't copy any of the gnucash lib/libqof changes into his
> project anymore. His changes since then in the sourceforge-qof project
> are not at all trivial (and ours in lib/libqof are important as well),
> so I think gnucash will not even compile anymore with his QOF code
> instead of gnucash's lib/libqof code (although I haven't checked).
>
> In effect, the outcome is precisely what has been mentioned before:
> Neil's QOF project is a fork of some part of the gnucash code. The
> forking has eventually happened in April this year. His QOF project has
> sufficiently diverged so that no direct substitution or merge is
> possible anymore.
>
> What does this mean to us? IMHO it means we don't have to treat the
> lib/libqof code in our gnucash repository any different compared to the
> other gnucash code under src/ (if we ever did). So at this point in time
> the answer to the open question from January is: No, the gnucash
> developers do not have to refrain from changes in lib/libqof other than
> what our normal development process would ask for. Just go ahead and code.
>
> * For example, the hard-coded installation path in the
> libqof/qof/qofla-dir.h header which is used only in qof/qofsession.c and
> nowhere else could probably be removed and the qofla-dir.h file be
> removed altogether. Same for src/engine/gncla-dir.h. Instead, if the
> installation path still needs to be specified at compile-time (which in
> itself is a bad idea) then this should go into config.h because that's
> where compile-time settings should be collected.
> * We could even move the whole lib/libqof directory back to src/libqof
> at some point in the future to distinguish it clearly from the
> goffice/gsf code copy.
> * The library itself has already been renamed to libgncqof.la in r14032,
> so there is no name collision anymore anyway.
>
> Christian
>
> Derek Atkins schrieb:
>> I propose we table this discussion until after 2.0 is released.
>> 
>> 
>> Chris Shoemaker <c.shoemaker at cox.net> writes:
>>> Developers,
>>>   Here's a proposal.  My understanding is that this proposal for a
>>> change of policy will not take effect until it is accepted.
>>>
>>> Proposal:
>>>    GnuCash developers should refrain from making changes (1) to QOF
>>> that are visible to users of the QOF API (2). (i.e. changes such that if
>>> the QOF code were copied to another program that used a previous
>>> verion of QOF code, the behavior of that program might change, or that
>>> might require changes to that program in order to preserve old
>>> behavior.)
>>>
>>>
>>> Do you agree to this change in policy?  
>> [snip]

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available