Hi Hank.
On Fri, 17 Oct 2014 11:31:26 -0400, Hank Grabowski wrote:
Gilles,
This is the original changes to get the bicubic spline working. These
were
originally committed as a diff that was attached to the JIRA
incident. The
suggestions in your email were in response to my questions about work
carrying forward from that point.
I have been very explicit and verbose on what I was doing throughput
the
development of those upgrades, both within the JIRA incident and
within the
forums. I attempted to incorporate all the comments that I received.
I
submitted my code in a way that could have been reviewed. If that
isn't
clear then I apologize, however I don't appreciate the connotation
that
these changes were done willy nilly or in a rogue fashion.
I can assure you that there was absolutely no such connotation.
The heat was not directed at you.
It was only the result of my being surprised by a totally _novel_ way
to
include code from new contributors. Luc has described what has been
going
on, and it might well be a good way, but I've been surprised that this
all
happened without adorning comments.
For an example of how I used to work with a contributor, please have a
quick look at
https://issues.apache.org/jira/browse/MATH-816
and
http://markmail.org/message/3uwilnca3bctcujc
I was thinking we were in a similar situation.
It seems we are not, because the tool has changed.
I still have to get used to it. It would help if I could read
explanations
about the new way, and how it came about due to using git, and how to
use
git to review code made by others (using branches, and I don't know
what
not) while working on unrelated issues and making my own modifications
in
my local copy...
Regards,
Gilles
Because I want my future contributions to be appreciated and not
disrupted
I would like to know how to do this process better/differently. I
don't
intend to put substantial effort into development and communication
to have
yet another reaction like this. It is as or more frustrating to me
as it
appears it is for you.
Sent from my Android phone
On Oct 17, 2014 10:24 AM, "Gilles" <gil...@harfang.homelinux.org>
wrote:
Hi.
On Fri, 17 Oct 2014 10:46:53 +0200, Luc Maisonobe wrote:
Hi Hank,
Le 16/10/2014 20:20, Hank Grabowski a écrit :
OK. I submitted the pull request yesterday. I'm going to now
remove the
diff from JIRA.
https://github.com/apache/commons-math/pull/2
Thank you. I have merged this request and pushed the result to our
main
repository. The only changes I introduced were fixing end of lines
in
the new Akima spline files (main and test). Perhaps you should
check the
git setting core.autocrlf on your side.
It seems to me this pull request did not make it to our dev list.
Did I
simply miss it or is there a problem in the GitHub setting since we
updated our repo? Did someone else see the request? If nobody saw
it, I
think we should ask infra to fix the settings.
I didn't see the request.
I also did not see the changes before they were committed.[1]
I have no problem with the principle of dropping broken code; but I
have
one with figuring out when it is okay to do so without notice,
ignoring
that care be taken with such changes.
I had suggested to not touch the existing classes and that they
should
be first deprecated, and then removed. Since several alternatives
for
implementing the functionality were proposed, it would have been
sensible
to have an agreement on how to fit them within the library (for
example:
an abstract base class and concrete subclasses for each kind of
spline).
In CM, we've had, on one hand, small, trivial, changes that
generated a
lot of unwarranted heat and stalled for days or weeks. And on the
other,
here is an example where big changes are pushed without a
discussion.
When I dare to make a suggestion about something,[2] it means that
I took some time to think about the proposal; the minimum of respect
for this commitment is to acknowledge the existence of such comments
and provide an explanation as to why it is better to not follow the
suggested path:
http://markmail.org/message/tjengf3t6j3hqyph
[If alternative views are really so different that a compromise
cannot
be reached, it is quite simple to count the people who have
expressed
their preference from a list of alternatives (as Phil often posts).
In this instance, only I have expressed my preference; hence I do
not
understand why something else has been committed.]
My opinion is that we should have created new classes containing the
working implementation(s) of the interpolation, and deprecated but
kept the old ones at least up to release 4.0, advertizing (in the
release notes and in the Javadoc) that they are not working properly
(although they follow reference "such and such"). [Someone might
have used that window of opportunity to point to the root cause of
the issue.]
So, was there a problem with that approach?
I'm sorry if this naive questioning looks trivial to some of you,
but I'd honestly like to know if this project is team work, and how
it's supposed to work in practice.
I'm also sorry if this rant has been caused by a simple overlook
of the post I'm referring to above. However even if it's the case,
there is a problem.
I hope I'm not being misunderstood[3]: it is great that Hank
could fix CM's spline interpolators.
In this opinion, I'm only concerned with the overall aspect of
contributing to a project that purports to be more that a bunch
of hooks to math functions, and about the design of which people
who have been contributing for some time might have earned (?)
the right to be listened to.[4]
Regards,
Gilles
[1] And I'm also not yet comfortable with looking at large changes
due to my surely inefficient handling of "git"...
[2] This is already after the self-censorship filter, on issues
where I know in advance that challenging the adopted view will
either be ignored or go nowhere... :-}
[3] As is often the case by people who do not carefully read what
I write in this forum.
[4] Which, I know, is not the same as being heard, and even less
being agreed with. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
