Thank you for the clarification. I like the idea of a commons-math base component, suiting the commons mission.
If commons math were transmuted to a large scale new math project, that competes with Hipparchus. Both projects are forks of the same scope and at the same time. But in the Hipparchus case, the decisions are made by the people who contribute to the library, and further, there are (I gather) more very experienced contributors. Here the decisions on math are mostly not made by people who contribute to math, and the experienced contributors have dwindled. I'm sorry but I think the reality is that such a project won't compete. Certainly if I had to choose, I would probably prefer the other fork, though in reality without commons-math I would just move my energies to GNU Octave and ImageJ. Gilles does not think that the new project will compete either. In response, Gilles is trying to reshape commons-math in a way that will have an important and unique place in the world and attract users, uses and support. This is a code base that interweaves successfully with the commons mission and code base, with the potential for growth in the form of small auxiliary modules driven by enthusiasts. A base commons-math could draw broad support from the community for some relatively easy to maintain components that really are in common use as the enthusiasts come and go. Personally, this suits my interests which are not extravagantly mathematical. I really just want to smooth the terrain between commons, ImageJ, GNU Octave, and JoCL to maximize my open source scientific computing pleasure. I'm just as likely to contribute to commons-lang if that aids these goals. I can only speak for myself of course. Maybe four simultaneous votes was not the smoothest way to continue but it allows Gilles to get going, while the iron is hot. No one has voted -1 so perhaps Gilles should start the branch and let us know what it is. I don't anticipate posting any more comments on these matters, but if Gilles starts a new branch I will show up for work. Eric On Thu, Jun 23, 2016 at 2:53 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > My answer would be slightly different. It doesn’t. All topics related to > the code should be deferred until we know what is happening with the > community. > > Ralph > > > On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann <jochen.wiedm...@gmail.com> > wrote: > > > > It doesn't, at least in my opinion. If the future Math project decides > > to have a "base" component: Very well. But, if the other components > > are elsewhere: Why should the base stay at Commons? > > > > > > On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill <ericbarnh...@gmail.com> > wrote: > >> There has been a lot of support in the discussions for, as Emmanuel put > it, > >> a "base commons-math > >> component". > >> > >> Where does that factor into this proposal? > >> > >> On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann < > jochen.wiedm...@gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> I'd like an attempt to put an end to all those discussions regarding > >>> Commons Math (CM). That means, in particular, that we find an common > >>> agreement on a course of action. So, here's a suggestion (might as > >>> well call it an offer, because acceptance would mean a lot of work on > >>> my side) > >>> > >>> 1.) I'll write a proposal to move CM to the Incubator. > >>> 2.) We'll wait for the Incubators decision. If the Incubator accepts > CM. > >>> 3.) If the Incubator rejects CM, then I'd start another formal TLP > vote. > >>> 4.) If the board accepts the TLP: Very well. > >>> 5.) If not: So what. Now we know, at least. > >>> > >>> In either case: At the end of the procedure, we'd have clarity. This > >>> will allow us to focus on a smaller set of issues (technical), and we > >>> can go on. > >>> > >>> The important part, to me, is to find something on which we can agree. > >>> That doesn't mean that everyone is happy with the outcome, but that > >>> everyone's got the feeling "I can live with that". In particular, > >>> there must not be any serious opposition later on. If you'd like to > >>> oppose: Please do so here, and now. > >>> > >>> Thanks, > >>> > >>> Jochen > >>> > >>> > >>> > >>> -- > >>> The next time you hear: "Don't reinvent the wheel!" > >>> > >>> > >>> > http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > > > > > > > > -- > > The next time you hear: "Don't reinvent the wheel!" > > > > > http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg > > > > --------------------------------------------------------------------- > > 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 > >
