Confusion about use of G2

Chris Shoemaker c.shoemaker at cox.net
Sun Oct 2 14:46:44 EDT 2005


On Sun, Oct 02, 2005 at 09:17:46AM +0100, Neil Williams wrote:
> -----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.

Care to explain that?  I was more thinking about practicalities such
as developer time and efficiency.

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

I recommend it.

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

You get massive patch breaking due to code churn?!?  What code has
been churning under you? Surely not GOG.

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

Sorry, this is not a convincing argument.

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

Some are.  Some aren't.

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

Of course.

> 
> | (*) 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.

There might be a logical leap here.

1) QOF needs release imminently.  [ Let's take this as a given. ]

2) GC needs to use QOF as external library.  
    [ I'm not exactly sure how strong a need I would admit, but let's
assume this is completely true. ] 

3) Therefore, GC needs, in the next G2 release, all these
architectural changes to support the new release of QOF.

I don't see 3) following from 1) and 2), but feel free to make the
case.

Don't assume that everyone knows what you know about the wonderful
benefits of QOF.  Please explain why G2 can't be released, with
feature parity with "G1", without architectural improvements.  Note
that it's not enough to simply explain how great QOF is for GC.  Lots
of things are great for GC that won't be in the first release of G2.
Why should all these QOF changes?

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

Again, fine, let's assume cashutil is wonderful.  Do we have to make
architectural changes to G2 to work with cashutil in order to achieve
feature parity?

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

[I'm assuming you're thinking post-G2 release here.]  So you *do* see
a distinction between architectural changes that should wait until
after G2 is released and those that are necessary now?  Could you
explain what that distinction is?

Thanks.

-chris


More information about the gnucash-devel mailing list