Profit and Loss Statement for Closed Books

[Colin Scott]

> While I appreciate your point of view, when someone is adding a 
> feature to the main code it's a chore to go and test every report to
> see if the new feature affected the output of the report.  The
> feature-writer may not even *use* some of the reports, so may not
> even know what the report output was supposed to be.

I must confess to being a trifle bemused by your point, which seems to imply a lack of modular design (or failures in modular design) that I frankly find pretty hard to believe.  I would expect, for example and as a matter of good design, account selection to be completely standard, fully tested, and available as a simple plug-in function.  If it works in one report, it should work in all of them - were it otherwise I should consider there to be a serious flaw in the design or implementation of that feature!  Similarly, I would expect basic data retrieval for those selected accounts  also to be available as a standard, tested, plug-in function.  

I will admit that I have never worked on open-source development, but I cannot see how any significant project could be conceived were such basic concepts of modular design not incorporated at an early stage.  And yes, of course, even good modular design isn't a magic bullet, but that and proper testing do make software more robust and less prone to regressions, and generally makes the regressions that might occur easier to track and fix.

> You're welcome to get your elbows dirty and help out, 

I would be delighted to do so, but I must confess that my skills, such as they were, and my brain, are probably too rusty to revive sufficently for me to grapple effectvely with a completely new language like guile/eguile.    Now, were the SQL database to make the data available in some suitably rational form then I might well be able to revive my Perl and SQL skills sufficiently to make a modest contribution (always assuming no religious objections to Perl within the gnucash world!  :-)  However, my attempts to build a set of basic views to enable access to the data in the fairly simple-minded way that I (and reports!) would ideally need have so far been less than successful.

> but complaining here isn't doing anyone any good.

I would hope that all participants in the gnucash project would be open to views expressed in here.  They may not agree with them, and they may not feel able to do anything about them in the short term even if they do, but I would expect user views expressed in here to have some affect on the development priorities and direction of the project in the longer term.  (Of course, views conflict, so some would win and others lose in this process.)  In any case, to expect everyone expressing a view to do it themselves is, in my view, even less reasonable than to expect an expressed view to be taken up and actioned instantly ...

Colin