Finishing the neverending QOF flamewar

[Benoit Grégoire]

On January 29, 2006 04:58 pm, Chris Shoemaker wrote:
> On Sun, Jan 29, 2006 at 02:13:50PM -0500, Benoit Grégoire wrote:
> > Neil has always been polite and argued with you on technical grounds.
>
> I agree that Neil's public emails have a certain tone of civility
> that I can't bring myself to reciprocate.  I also recognize that to a
> casual observer this may appear to be a technical discussion.  I
> assure you it is not.  It is completely political. 

Ok, I admit I oversimplified trying to show the argumentative pattern the two 
of you are following.  I did not even try to follow the specific technical 
issues.  I don't know which one of you is right.  I unfortunately lack the 
time to follow gnucash developement closely for the time being, but I try to 
not completely disconnect.

> > Neil has shown his willingness to bend over
> > backwards to help make changes in QOF as unobtrusive as possible for
> > GnuCash's development process,
>
> This is simply not true.  How is disabling GnuCash's logging facility
> and leaving it broken for months "as unobtrusive as possible"?

Abstracting a core part of a software package to make it independently usable 
from other applications is inevitably going to cause a short term loss of 
efficiency for the original software.  Sometimes (some would say most of the 
time) that loss is never recuperated by the original project in the form of 
long term benefits.  

So what "as unobtrusive as possible" means in this context is open for debate.  
But it clearly doesn't mean "doesn't change the way we do things or add any 
additional overhead".

I don't know how loging got broken, and who is right.

> I completely agree that Neil deserves to be treated with respect.  I
> even would say that that respect doesn't need to be "earned" but
> should be afforded to anyone by default!  But, that needs to be
> balanced against the benefit to the users of GnuCash.  Neil's recent
> behavior has been to make rather invasive changes that were not
> approved of by any other developers, and which broke functionality and
> introduced subtle data corruption bugs.  Now, he's using the _ruse_ of
> maintaining library compatibility to claim exclusive ownership of QOF.

Well, he is trying to assert maintainership over that piece of code, I didn't 
feel he made any secrets about it.  Furthermore no one has offered to do it 
in his place.

> So, how would you balance Neil's deserving of respect in this case
> with the user's deserving a GnuCash whose core is developed by more
> than one person?  I struggle with this question, so if you have a
> suggestion I'm interested.

Well, while it's no magic solution,  I'll try to bluntly list the real issues 
the two of you have as I perceive them.

First issue:  The GnuCash project didn't make a clear commitement that it 
would maintain QOF as an independent library, with it's own release schedule, 
causing a lack of trust by Neil and other users of QOF that their needs are 
goind to be given due consideration.  Normally, we'd have to chose between:  

1-The GnuCash project maintains QOF as an independent library in the gnuCash 
repository (that means giving equal merit to the needs of other projects, 
maintaining a separate build system, accepting patches in a timely manner, 
giving commit access to people who would commit frequently to QOF even if 
they never even build GnuCash, etc.) Then we can expect everyone else to sync 
to our copy.

2-Developpement occurs elsewhere, we are just one of the stakeholders, and we 
sync to "their" copy.

3-We don't give a rat's ass about cooperation with other projects, we tell 
those who want to use QOF good luck, take it, we never want to hear about you 
again.

Normally those three things would be mutually exclusive.  Lucky for us, we 
also seem to have:

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.

That's a political and philosophical issue.

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.  A fork is 
an inevitable consequence or 3.

Third issue:  How to handle code quality while QOF undergoes this transition.   
This is a trust, time and communication issue.  Neil may or may not have the 
necessary skills and experience to maintain and sync QOF on his own.  If he 
does, he's still just a human being, and keping large codebases maintained in 
two places will inevitably causes glitches, especially during API changes.  
If he doesn't, there's still only two things that can be done: replace him or 
help him.  

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.

Fift issue is the specific mechanics of cooperation.  How often do we sync 
changes, how large the syncs should be, how do we handle the build issues, 
release schedules, etc.  That's a process issue.  I tought a reasonably clear 
process was outlined, but it may be worth writing a step by step list.

The two of you seem to have spoken or unspoken disagreements on all five, and 
probably most other developers have (or had) disagreement on at least one.

There should probably be a discussion of each one individually to reach a 
consensus, and settle with some sort of vote if there if one isn't reached.

We can then move back to real technical issues in a productive climate.
-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- 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/05230b23/attachment.bin