Reports: Utilization of urls
carsten.rinke at gmx.de
Sun Mar 13 13:49:33 EDT 2016
"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
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 :)
More information about the gnucash-devel