On Wed, Jan 11, 2006 at 06:43:36PM +0000, Neil Williams wrote: > On Wednesday 11 January 2006 4:23 pm, you wrote: > > Should GnuCash use an external QOF library? > > At a packaging level: > Wherever QOF is available, yes. > Wherever QOF can be made available, also yes. > > At development level, I'm reasonably happy with a copy of QOF copied into > gnucash prior to a QOF release.
I'm not too happy with large chunks of unrelated QOF development being committed at one shot. I suppose more frequent syncs would diminish this problem. OTOH, I could try to follow the SF CVS commits, but they don't seem to be very incremental either. [snip] > Using QOF externally in development isn't the issue, anyway. Just coordinate > with me when you work in lib/libqof. What _exactly_ does this mean? I'm reading this as "email me your patch and wait for an acknowledgement before committing." Am I close? > What I ask is: > 1. Coordinate with me before committing changes to lib/libqof - unless the > changes are a CRITICAL bug. Even then, let me know *urgently*. > 2. Always keep in mind that there is as much of QOF outside gnucash as there > ever could be inside and don't make changes that are gnucash-specific. > (i.e. do not use gnucash defined macros or build structures.) This is > imperative in an embedded environment. > 3. Listen in on QOF-devel just to get notice of latest developments and > releases. > 4. Do nothing to increase or modify the existing dependencies of QOF. > > > I think the disadvantages of Gnucash using external libqof are > > inconsequential at a packaging level. > > > overwhelming, but let's at least ask what are the advantages? Well, a > > user who used external libqof for both gnucash and gnotime would save > > a few kb disk-space. > > QOF is going to be updated far more regularly than gnucash, that's beneficial. Can you release a libqof _every_ time an API change is made and increment the corresponding Gnucash "requires qof > x.y.z"? > > In *theory*, an external libqof would be > > maintained by non-gnucash developers, gaining labor efficiency. But, > > in practice, allowing external libqof means gnucash-developers have to > > become libqof developers, with additional overhead labor and _reduced_ > > efficiency. > > ? Nobody from here has to join me in QOF development, I don't see the problem > or any additional overhead. See above. Your "coordinate with me" sounds pretty much like additional overhead. > No gnucash developer needs to be diverted or become a libqof developer. I'll > do all that - as long as the gnucash developers respect the division. > > > 1) Continue libqof development in gnucash svn, build and > > release external stand-alone libraries from this source, even though > > GnuCash won't use them externally. > > Impossible. libqof cannot be developed in gnucash svn. It has outgrown > gnucash > and is going into places that gnucash simply cannot follow. Completely > inappropriate. This is hard to believe. If external QOF builds and it can be synced to lib/libqof and built for internal purposes, how can libqof not be built and developed from lib/libqof? > It's hardly suprising that I've still got some cashutil code outside gnucash > svn. I may yet take cashutil to a separate repository - especially as nobody > here appears to have even looked at the branch. > > > 2) Fork the code from the gnucash qof, develop and release it > > independently from Gnucash. > > It is already developed and released independently from gnucash. I don't see > the need or benefit for a clean fork, it's just wasting even more effort. Ok, so you've already forked then. Please don't complain that people aren't keeping the code you forked from compatible with your fork. > Is it really that hard for a free software community to actually SHARE? > > I'm willing to keep gnucash updated with the latest QOF code but I will not > make duplicate commits for every single change. Neither can I use gnucash svn > for QOF development, it flies in the face of everything I want to do in QOF. Huh? What does it matter where the code is stored? What can you do in SF CVS that you can't do in Gnucash SVN? > The best I can do is update lib/libqof prior to each QOF release. > > > One implication of this is that merges > > into gnucash svn's qof should STILL be incremental and reviewable NOT > > huge "sync with external QOF version blah". That really bothers me. > > I'm not going to start committing the same change to two trees every time! > That's a complete non-starter. No matter how much it may bother you, it ain't > going to happen! > > > In any case, just to make things clear: I'm advocating > > disabling the option to build Gnucash with external QOF. > > Absolutely bonkers. No. It's not. Look. Today's Gnucash from svn WILL NOT WORK with the most recently released libqof. What are the options? 1) Disable --with-qof so no one tries and fails. 2) Leave it broken. 3) Release a new QOF ASAP. Tell people not to use --with-qof until the new version comes out. 4) Just tell people to never use --with-qof. 5) Revert /lib/libqof back to the state after your 0.6.1 release, along with GnuCash changed that depend on those qof changes. Stop development in /lib/libqof and any avoid any improvements to gnucash that would require changes to /lib/libqof. You tell me which of those is most bonkers. > Do you want me to provide a patch that re-enables it for sensible packaging? > > I only ever build gnucash with internal QOF prior to a QOF release. > > > The only > > reasonable alternative is to stop development in /lib/libqof when > > external QOF does a release. I'm strongly against that alternative. > > There IS NO development in lib/libqof (that's why it's no longer under src/). Do you realize how that assertion is ... > > QOF development happens at SF, it is discussed via QOF-devel and released > early and often. > > What happens in gnucash svn merely supports the SF development. ... completely incompatible with this one? -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
