Hey folks,
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.
Now I understand any such policy is merely an ideal whose
actual application must also consider many practicalities.
Nevertheless, I've been sitting on a stable, complete implementation
of budgeting since the spring, (I actually use it for my own
budgeting.) along with lots of other general improvements to
e.g. tracing, testing, debugging, etc. As soon as G2 is released and
a "dev" branch opens I was planning on pushing for inclusion(^).
Since then, I've also made substantial progress on a
register-rewrite using the GtkTreeModel API. It's been easier than I
thought. (Although I've made no progress in the past 2 months - no
time.)
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. 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.
Now, honestly, even though I have a *MUCH* better
understanding of GC's code base than I used to, (It actually feels
comfortably familiar these days.) there's still stuff I just don't
understand because I haven't looked into it. However, I'm starting to
see that much of the patch breakage isn't from bug-fixes but from new
functionality/improved architecture.
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.
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. Should I smack my forehead,
refresh my patches and push for inclusion, clearing my decks to get
back to the register-rewrite? Or, can we open another branch for new
development? Or, can we just decide not to make wonderful
architectural improvements(*) in G2?
-chris
(^) I know there's an incomplete budget in G2, I was expecting it to
be removed for G2. Incidentally, I believe my budget implementation
should be easier to integrate with QOF than the existing
implementation, since it defines fewer object types.
(*) 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.)
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
