Reports: Utilization of urls

[Carsten Rinke]

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?

Regards,
Carsten

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
>