-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Shoemaker wrote: | I'm hoping someone can clarify for me a confusion about the | state of the G2 branch. My understanding was basically that G2 was | feature-frozen like an "rc" kernel - "get what's there working" - | "bug-fixes only" - whatever you want to call it.
? It's a branch for code that requires Gnome2. | Now I understand any such policy is merely an ideal whose | actual application must also consider many practicalities. One of which is spinning out QOF. This patch has gone a long way to achieving that but more needs to be done. | Now, I figured it wouldn't be that tough to maintain these | patches (about a dozen) out-of-tree, and tools like 'quilt' have sure | helped. I'll have to find some time to look at quilt - it could help with my own patches that are needed to build gnucash on OSX and Debian. | But, there has been a lot more patch breakage than I | expected. Of course, that means more time spent refreshing. It has | noticeably diminished my time available for new dev work. I get the same with all the GOffice code and it's dependencies. Then OSX has horrible problems with the frequent use of -module in the makefiles. | Ok, let me be very clear: I'M ALL IN FAVOR of improved | architecture. But... I don't want to maintain out-of-tree patches | against a tree that's undergoing architectural improvements. If G2 is | a "dev" branch, then I should have pushed for submission of many | patches a LONG time ago (my fault). If G2 is a "bug-fix-only" branch, | then it shouldn't slow me down so much to keep my patches fresh | against G2. The tag is gnucash-gnome2-dev so it is a "dev" branch - that's my understanding. | So, which is it? Neil's tracing patch naturally breaks almost | every patch I have - not to mention the trace system improvements I've | been sitting on until G2 was released. I wish you'd said something when I started talking about trace changes on this list. Are these changes compatible with using trace via the external QOF library? However, the fix for your out-of-tree code could be a copy of how over 250 other files have had to be changed from a short int identifier to a const gchar* identifier string. | (*) I know *some* architectural improvements are necessary to make G2 | work, but is QOF one of them?! The more I understand about QOF, the | less essential to a quick release it seems. (I'm ok with a G2 release | with only XML file backend.) QOF needs a stable release imminently for use by other applications. It is already on pre-release. Gnucash needs to use QOF as an external library. There shouldn't be too many changes left to make - the backend is the main one, changing from gnc-module and scheme to GModule and dlopen. It's working in cashutil, but I stopped short of putting it into this commit. Then there are the changes required to work with cashutil - again these are architectural changes to libraries and makefiles, as well as the abstraction of the GUI logic into a library to be shared with cashutil. I've got a usable undo framework out-of-tree and it will stay there for now. I'll also be implementing the logic abstraction out-of-tree. I can't introduce those to the gnucash tree until gnucash itself is closer to accepting cashutil which in turn requires a completed QOF spinout. - -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDP5epk7DVr6iX/QIRArvBAJ9+2bE+CdjgEGFuwlbgzq+Ka09ARwCfWzg5 eFyXxNgiTxkTy/z6VYccuCI= =VsBU -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
