Re: [Math] Disagreeing about how MATH-1138 has been handled

[Gilles <gi...@harfang.homelinux.org>]

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" <gi...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org