[Patch] Bug 712640: gnc-engine.c parallel optimization

Geert Janssens janssens-geert at telenet.be
Tue Nov 19 08:39:28 EST 2013

Hi Alex,

I'm sorry you got off on such a rough start.

I don't think you should apologize for anything if you were working with the best intentions. 
John has a direct way of saying things, but don't let that scare away. Just learn from your 
mistakes and the feedback you get on them.

Regarding the code you wrote: I agree with John. It's too soon to go adding mp support at this 
stage, even if it's only optional. For sure people will enable it and run into all kinds of 
unexpected issues. As our development team is small, that would cost us much time in support 
that could be better spent in improving the program.

I am fine though with your other suggestion of replacing magic constants and other minor code 
cleanups. If that can help you getting more familiar with the code base that's fine. Do keep in 
mind though that much of the lower level code is due for a thorough refactoring/conversion to 
c++. That's what John was trying to point out: much of these small changes risk getting lost in 
that major overhaul.

Another suggestion would be to work on unit tests. I read you are not familiar with it, but this 
may be a good time to learn it. The benefit of starting with unit tests is that it will also help you 
get familiar with the code base. Many parts of the engine are still missing good unit tests. This 
work has only started in the 2.5 development cycle.

Then concerning the documentation. As I see it your intentions were misunderstood and John 
reacted rather harsh on it. Again don't let this scare you off.

The wiki is really meant to be edited by anyone. We could consider moderating all changes, but 
again that would put a large burden on our small development team. I practise I believe such 
moderation would simply lead to wiki changes dying in the moderation queue. Instead we 
assume all contributors are well-behaving and make thoughtful changes. There is some 
moderation to weed out blatant spammers. That in itself already takes enough time.

Also when the development guidelines talk about writing documentation, this doesn't mean 
adding something in the wiki. The documentation is kept in a separate repository and should be 
updated for user visible changes (new menu options, different buttons in a dialog,...).

In general there's one golden rule: if in doubt - ask. You are very eager to dive in, which is good. 
But ask often instead of assuming.

You were talking about a page to guide newcomers. The hard part of such a page is that an 
experienced contributor doesn't look through a beginner's eyes anymore, making it hard to see 
the holes in our existing documentation. So I invite you to improve the documentation we have. 
But be sure to ask for feedback on your thoughts early on !

I'll stop here. These mails are getting way too long...


More information about the gnucash-devel mailing list