Finishing the neverending QOF flamewar

[Neil Williams]

On Monday 30 January 2006 4:54 pm, Chris Shoemaker wrote:
>   Relatively speaking, I am _not_ bothered by Neil breaking logging.

(I didn't break it, let's not start all that again. Change the record.)

There is actually NO reason to discuss all this now - this should all wait 
until after G2 is out. That is MY priority right now and this discussion is 
wasting ever more of my time. Please can we drop this!

> I think it was an honest mistake due to some lack of testing, and it
> was easy to fix.

You're still missing the point. It was the default and the else{} that was 
wrong.

>   In fixing it, I improved the logging API, without affecting any
> existing QOF program. 

Once again, Chris, that is inaccurate. Implementing logging for modules that 
do not explicitly set their own log level DOES break functionality in other 
programs because those programs want to use selective logging. This is the 
opposite of the "log-everything" habit of gnucash. If a module does not set 
it's own log level, the library supports ignoring that module completely. 
Your change to _global meant that once _global was called with a real 
log-level value, all those silent modules would be silently enabled.

I accept _global needs to be renamed but that does not mean it is right to 
close off selective logging. It is incredibly powerful in debugging - 
something that I should have been doing these last two days instead of 
answering your increasingly desperate posts.

> Not a single message of any type, anywhere, is 
> logged with my patch that wasn't logged before, nor vice-versa. 

You have no evidence for such a statement. I attest that messages ARE logged 
that should not be logged because of the change - or would have been if I'd 
implemented it in QOF CVS.

(If the change made no change to logging, why all the fuss?)

> There 
> is simply no technical disadvantage to my change.  It is 100%
> compatible with every existing usage with no change, and it makes a
> useless function useful.

Wrong. The "useless" function you refer to is probably _global which, I 
accept, is misleading named but still functional. If I'd actually had time to 
fix this instead of wasting time on these endless discussions, I could have 
made some progress this week. As it is, your incessant posts have meant that 
I will get no further work done this week due to pressing commitments 
elsewhere. Thanks a lot.

>   I don't have _any_ problem with Neil being the maintainer of QOF.
> None at all.  Using a false justification of incompatibility to revert
> of peopele's changes is a claim to _exclusive_ maintainership.  I _do_
> have a problem with that.

The title of this thread was to finish this waste of time. You are just 
perpetuating it.

FINISH THIS. NOW.

I propose there should be no further discussion of this whole area until AFTER 
G2 is out. I'll manage as best I can in the meantime and release libqof1 at 
such points as are necessary for the external programs and for gnucash 
releases. Beyond that, the matter MUST rest until gnucash 2.0.0 is OUT.

> > 4-One crazy person commits to keeping two repositories in sync to allow
> > everyone to develop where it's natural for them to do, giving some of the
> > benefits of 1 and 2 at the same time.  That's a very hard job, and it
> > requires that the participants of both repositories at least agree that
> > QOF is to be considered a self contained, generic library.
>
> ... and agree on who has permission to make changes.  I honestly don't
> see why Neil thinks it's more natural to develop QOF on his own rather
> than in GnuCash's repo, but I don't have _any_ problem with his doing
> so.  I just don't think that should mean that I can't change QOF anymore.

As long as you are willing to accept that there are other uses of these 
functions that are beyond their purpose in gnucash.

>    BTW, there is another option.  I think that Neil has placed _way_
> too much emphasis on packaging QOF - to the detriment of true
> collaboration and sharing of QOF code.  An obvious option is to
> continue devloping QOF where it has been developed until it's really
> ready to stand on it's own. 

(It already is ready.)

> In reality even this isn't a downside, because I would expect that the
> tree where QOF is developed would be constantly releasing with a QOF
> version later than had been copied to the other programs.  And that's
> _good_.  It means that QOF can continue to develop with changes that
> aren't 100% backward API-compatible because no external programs will
> use the newer version until they sync with the development tree.  At
> that point, they can adjust for any changes in API.

Unmanageable. The SONAME would be pushed beyond any reasonable limits. Do you 
want libqof32 ?

>    _OR_ If Neil really wants those other QOF programs to use external
> libraries, he can always package libraries from the development tree.
> The point is, QOF is not mature enough to stand on it's own.  It needs
> to mature within a development community larger than 1, and
> practically speaking, that means that development on QOF within
> GnuCash _must_ continue.

As long as the needs of other programs is considered.

>    Furthermore, because QOF is not mature enough to have a stable API,

It does have a stable API and will remain so until libqof2 when all this 
deprecated stuff will be removed.

> we must be free to make changes that are not backward compatible.

Not true. Adding interfaces is acceptable, as is deprecating old ones, but the 
old ones must remain and the library must still be usable by older programs.

> That means that releasing a library of QOF is no different than
> copying the source -- every release may require changes to the QOF
> programs. 

This is exactly the nightmare that we had when Linas packaged QOF. It is 
unmanageable and irresponsible. Not a good way of sharing code.

> Any other QOF programs that use an external library should 
> lock to the one version they have been tested with.

!!! Have you ANY idea how difficult that becomes !!!

> > Second issue: Keeping QOF usable by other project requires additional
> > work to be performed, delaying 2.0 by some unknown amount of time. 
> > That's an inevitable consequence of the first issue if 1, 2 or 4 is
> > chosen.
>
> There are different degrees of additional work required by the
> different options.  We're certainly not taking the easiest and least
> disruptive approach to sharing code with other QOF programs.

For whom? 

> > A fork is an inevitable consequence or 3.
>
> Forks are good. 

Forks are bad. Forks prevent sharing, sharing is the essence of free software. 
If we can't share we might as well all give up right now.

> Neil has choosen to keep a 
> copy in such a way that makes it difficult for him to merge his
> changes with the common source that has been developing in GnuCash's
> repo.

Not true. A little copy and paste is all it needs. Besides, nearly all QOF 
development now happens outside the gnucash tree. There is no good reason to 
reverse that.

Building gnucash takes FOREVER and testing changes becomes an interminable 
minefield of frustration and twiddling thumbs. That is why I started doing 
translations and the website - something to DO whilst waiting for gnucash to 
build.

Building QOF is fast, I can make, test, build and distribute changes in a 
matter of hours. GnuCash takes months.

> It's completely understandable why he wants to revert 
> improvements to lib/libqof.  Every change makes more work for him.

Wrong, I will gladly accept changes in qof that consider the needs of the 
other programs and which are not gnucash-specific.

It is very little work to copy changes between the two trees - the work comes 
in getting others to understand why gnucash ideals will NOT work for external 
programs.

> I think I can speak (with great caution) for all the GnuCash
> developers in saying that we want to _help_ Neil, not replace him.
> But it's very difficult to help him when his development is in
> isolation.  Even the infrequent commits to SF CVS are too far removed
> from the people who can help.  We _want_ to help - we want to help
> _here_, not at SF.

And I'm the one acting as the gopher between the two. That's fine, I committed 
to that some time ago. That hasn't changed. I don't like svn, I do like SF. 
If you want to help me, let me work with tools that I actually like to use. 

> > Fourth issue (that received surprisingly little attention), is exactly
> > where QOF starts and end.  Some features of QOF may not really belong in
> > the core QOF library, conversely some issues may be resolved by moving
> > services into QOF.  That's an architecture issue.

FTR, I'm perfectly happy with what is in libqof1. If you look at the actual 
Makefiles, there are some files that are no built but these are not used in 
gnucash either. All the rest is as fundamentally important to the external 
programs as to gnucash.

gnucash is another qof process - I try and deal with each equally but that 
means that the needs of gnucash do NOT take priority.

> This is a HUGE issue.  It's the MAIN issue why I'm unconfortable with
> GnuCash using an external QOF.  It seems that the decision boundary
> for what moved to qof was something like "whatever code could be used
> by multiple projects." 

That's a good way to share code - it means pilot-qof and gpe can get the 
benefits of what began in the gnucash engine without the overhead and without 
extraneous code. Every part of QOF is used by these external programs.

> That's a poor way to build a library.  I think 
> more than 50% of what's in libqof doesn't belong.  I also thing that
> the querying infrastructure and the serialization probably don't
> belong together.

By serialisation do you mean QSF? Other serialisation code within QOF is no 
longer built either in gnucash or libqof1.

> 1) Gnucash developers can still develop QOF.
>
> 2) Neil's in charge of copying code from svn to where ever he releases
> libraries from.
>
> 3) If we make non-backward compatible changes to QOF, Neil would have
> to reflect that in his library version numbers.
>
> One thing that I don't think was hammered out was should Gnucash 2.0
> use external QOF.  Neil has asserted that it should. 

I'd like it to do so and I will do what I can to allow it to do so but it 
isn't compulsory. It is, however, eminently sensible.

> 1) We shouldn't release 2.0 with external QOF unless we've tested it
> extensively with the version we're depending on.

Any version of libqof1 will be compatible. There are bug fixes in 0.6.1 and 
0.6.2 which mean gnucash will function better with those versions, hence I 
bumped the configure version to 0.6.2. You cannot fix an application to a 
specific version of a library because it breaks all the packaging systems. I 
want gnucash to be able to release, as far as bugs allow, independently of 
libqof1 and vice-versa.

> 2) We can't test with external QOF because we're frequently making
> changes to QOF that aren't backward-compatible.

Frequently? Two changes since this whole wrangle started?

If you had taken head of my notice of imminent release of QOF 0.6.1 then we 
could be using libqof1 0.6.1 NOW, for this upcoming gnucash release.

All I needed was a little email from you saying "I'm working on something that 
is in lib/libqof and hope to commit soon." then I could have delayed the 
release by a matter of a few days and included your CACHE_REMOVE change. No 
problems with that, none whatsoever.

> Note that this _doesn't_ preclude sharing QOF code with other
> projects, even in the form of an external library.  It's just a
> question of whether or not _GnuCash_ should depend on an external
> library for QOF functionality.

If you ever want to use libqof1 externally there does remain some need to 
coordinate with external qof development and consider the needs of external 
programs.

> It might be because they don't approve of my assertive tone.  It's
> probably because they'd rather write code than argue.  So would I.

And I. PLEASE can we stop this nonsense until AFTER G2. How many times do I 
have to ask! Stop wasting my time!

> Neil's words say that I'm free to develop QOF, but his actions are
> that 100% compatible improvements to the API are reverted.

Your else{} block is not compatible. It does not allow modules to be ignored 
for selective logging.

> I think it would be appropriate to have some _public_ discussion on
> this point. 

Just not NOW please!

> I'll post a question in a new thread to attempt to leave 
> some of the baggage of this thread behind.

It would have been better for everyone if you would simply drop the entire 
issue and let everyone else actually do the IMPORTANT things in life, like 
fix bugs in G2.

Drop this!

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060130/787f8418/attachment.bin