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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
