Reports: Utilization of urls

Carsten Rinke carsten.rinke at
Sun Mar 13 13:49:33 EDT 2016

Hi Geert,

"it is not a bug fix"
 From end user point of view I disagree, but I agree that this is not an 
item to waste energy on.

"several of your patches I did review and commit only to revert them 
afterwards again"
I think that references the
- cashflow calculation issue, which the patch was later-on declared 
"obsolete - not a bug, but misunderstanding of function"
- the overlapping x-axis label issue, that showed problems on other 
distributions, which I could not see in my environment

"unit test set available for most of our guile modules"
Even though I very much support this idea: I don't think that this would 
have avoided the problems above, especially as it is not feasible for me 
to run a mutli-distro environment.
For me the question is, if there is man-power available to qualify and 
verify the solutions and patches before they are committed, best case: 
in different environments.
My perception is that currently this all falls back onto only your table.
Is my perception correct?

Independent of that:
What do you have in mind with a "unit test set"?
You mean documentation as kind of work instructions for testing?
Or do you mean an automated test framework?


On 13.03.2016 14:39, Geert Janssens wrote:
> On Thursday 10 March 2016 18:58:56 Carsten Rinke wrote:
> > I have the same point of view regarding the categorization:
> > This is adding an optional representation mode to existing reports.
> > Not making up new reports.
> > This option is available already for the networth line chart (even
> > though differently implemented), so I rather see this a bug fix
> > instead of a new feature.
> >
> It's not a bug fix. The line chart views weren't there for these 
> reports so you're not fixing something that didn't work properly. 
> You're adding functionality that simply wasn't there yet. There's no 
> use in trying to debate that.
> Whether the new feature should be eligible for maint inclusion can be 
> debatable. You'll find my motivation for not including it below.
> > At the same time I see this a minor modification. So waiting 2 years
> > to make this available for other users .... that is a looooong way.
> > But it has happened before that I have underestimated the complexity
> > of the issue ....
> >
> It's not so much you underestimating the complexity of the issue. I 
> agree that the change itself in this case looks relatively small.
> The complexity comes from the state of the guile code as a whole in 
> gnucash. There is insufficient isolation in many cases. As a result 
> making a trivial change for one issue can easily break another part of 
> the code without any of us realizing.
> That's why I tend to be extremely conservative in making changes in 
> guile code in the stable series. I have underestimated these inter 
> dependencies more than once in the past (among others with several of 
> your patches I did review and commit only to revert them afterwards 
> again due to complications). In each of the cases I believed the 
> change was sufficiently local to be ok and was wrong. I don't feel 
> like repeating that exercise on a regular basis.
> If others want to review your patches and estimate whether they are 
> safe to include in maint, I'm fine with that. I will stick to my 
> conservative selection of only applying patches to maint I have 
> sufficient confidence in they won't break the code in unexpected ways.
> Note I would feel much more confident if we had a good unit test set 
> available for most of our guile modules, which we don't. If you feel 
> like it that's a very good area to contribute in as well :)
> Regards,
> Geert

More information about the gnucash-devel mailing list