Confusion about use of G2

[Neil Williams]

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