Hi all, Le 17/10/2014 16:23, Gilles a écrit : > 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 understand this, and in fact I even think it is much easier to check such changes by looking at actual code from our own development tools than from GithUb or something else. So this change should not be taken as some definitive version. We are using a version control system, and we can always iterate on such changed. As Hank does not have write access, committing this hopefully should help deciding on what is needed next. It's a fist version. We have to go back and forth between discussion and coding. This issue has already seen a lots of discussion. > > 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. It is fine to me. > > 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. It *is* part of discussion. Frankly, It seemed a waste of time to have several people not accustomed to Git try to read this from GitHub and import it in their own setup. I have done this for everyone else, and we can review here. > > 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.] The reason is I think I am the only one to have minimal Git knowledge for now here. > > 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? No problem at all. > > 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. It is team work, and your message proves it: there are several opinions and the final release is the sum of all. The version control system is *not* a final immutable thing, it is a moving thing, with experiments. Once everybody is fluent with Git, we will even be able to use more elaborate things. Branches would be great for such feature changes, but I think it is too early to use them for now. best regards, Luc > > 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
