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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
