Thanks, Eric. I am OK with Commons Math being split into modules in the Commons Math sub-project. I am not OK with Commons Math A, Commons Math B, etc existing within Commons. In other words, when a user traverses to Commons Math they can then see the modules that make up Commons Math.
I am also OK with code being mothballed if no one knows what it does, how it works, why it exists or who may want to use it. I am not OK with retiring code just because a single person doesn’t know what it does or how to maintain it. In other words, I am looking for people like you to volunteer to be part of the community that decides what should stay and what should go. IMO, that community needs to be of sufficient size that it is somewhat representative of the users of Commons Math. That doesn’t mean it necessarily needs 10 people, but I would say it needs more than 2. The side effect of this, is that once you have a community that can start making these kinds of decisions you can also make a proposal to go to the incubator or become a TLP (there is really no reason a project can’t “incubate” here in Commons). Ralph > On Jun 18, 2016, at 11:22 AM, Eric Barnhill <ericbarnh...@gmail.com> wrote: > > I am new to protocols here and not sure which thread to jump on. But I am > quite interested in the viability of the math project and hope the > following observation is helpful. > > I think one reason people are talking past each other in this debate is > because those outside the commons-math community may be thinking more about > commons-math classes like Median and those within it may be more concerned > with commons-math classes like AkimaSplineInterpolator. > > In the case of Median, the fit to the commons mission is quite clear. It's > a simple function that is widely needed and used but not in the Java API. > Commons as a whole is strengthened by classes like Median, and commons-math > is strengthened by being in the commons framework. And Median, probably any > of us could maintain. > > But a class like AkimaSplineInterpolator is a different matter. In that > case the fit with the commons mission is less clear. And in the case of > classes like AkimaSplineInterpolator, Gilles is right. It doesn't make > sense to carry a method like that forward to the next version of a package, > if there is no one around who even knows what an Akima spline is, let alone > can defend the methodology in the library or its accuracy. One can't have > a credible library for scientific computing if it contains methods, for > which no present maintainer can guarantee the accuracy or effectiveness. In > such case, such a class should probably be mothballed in the next release, > or spun off to be maintained by someone who knows what they are doing. (I > have offered to maintain the interpolators BTW.) > > So I actually see Gilles' proposal for spin-off packages as solving a > fundamental dischord in the way commons-math is set up. At the risk of > adding yet another proposal to the mix, what about deciding which of the > Math classes suit the commons mission, and are of fairly wide currency such > that developers from other packages in commons who have offered their help > could probably maintain them just as easily. This makes for a core CM. Then > for the rich array of more sophisticated classes that prompted calls for a > TLP math in the first place -- I can certainly understand the impulse -- > only one of two possibilities exists. Either a new community needs to be > built through incubator, or the classes with current support need to be > spun off, and new releases of those classes overseen by people who > understand them and want to manage them. > > Gilles feels a trip through the incubator is unlikely to bring new > mathematicians into the fold who want to maintain an omnibus math package. > His instinct here aligns with what I've seen empirically over the last few > months -- myself, Artem, syenkoc all have our particular agendas and niches > of interest that we want to maintain. Gilles says it was ever thus, and I > see no reason to doubt his knowledge of the history. > > So if the days of a core of several omnibus maintainers are over, we should > go with the other logical plan which is to spin off the fancier > interpolators, solvers, etc. -- classes that exceed the commons mission -- > into classes that have someone who understands them and wants to support > then, and classes which get mothballed for 4.0 . I think this makes a lot > of sense. > > I would only add that I think that all the math-related classes, as well > as all of commons, benefits from some sort of commons-math core classes > that we are sure belong in commons. And then there is no more debate about > whether someone is trying to destroy commons-math, which quickly becomes > acrimonious. I think this is a partitioning we could all achieve. We can > vote on every math package if you like! > > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
