You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Barnhill <er...@gmail.com> on 2016/06/18 18:22:24 UTC
apache, commons, math
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
Re: apache, commons, math
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi Eric.
Thanks for a refreshing viewpoint!
Gilles
On Sat, 18 Jun 2016 20:22:24 +0200, Eric Barnhill 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache, commons, math
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jun 19, 2016, at 3:13 PM, Jörg Schaible <jo...@gmx.de> wrote:
>
> Hi Ralph,
>
> Ralph Goers wrote:
>
>
>> Once there are enough active
>> committers then I would think they would become Math TLP PMC members when
>> it is appropriate.
>
>
> To me this means to keep CM alive as it is (multi-project or not), wait for
> a big enough community (in the incubator or here) to claim TLP and the Math
> TLP can then act with the code as it likes.
That is sort of true. There is really nothing stopping individuals from creating new forks or branches to at least demonstrate what they have in mind. In itself, that might help to get more people involved.
Ralph
Re: apache, commons, math
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote:
>
>
>> On Jun 19, 2016, at 10:40 AM, J�rg Schaible <jo...@gmx.de>
>> wrote:
>>
>> Hi Ralph,
>>
>> Ralph Goers wrote:
>>
>>> Thanks, Eric.
>>>
>>> I am OK with Commons Math being split into modules in the Commons Math
>>> sub-project.
>>
>>
>> That was my first idea too. But if the collection of all submodules will
>> in the end nevertheless only contain 20% of the code, we gained nothing.
>>
>>
>>> 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.
>>
>>
>> The main problem seems to be that CM was a dumping ground for all kind of
>> stuff that have at least the slightest relation to a mathematical base.
>>
>> Gilles never expressed it directly, but in its consequence he proposed to
>> move the current CM into dormant/attic and extract single parts of the
>> old code base as new components.
>
> Personally, I don\u2019t think moving it to the attic is appropriate. Projects
> go to the attic, not components. The Math project (or sub-project) is
> free to add or drop components as the see fit, so long as it is a
> community decision.
>
>>
>> Some of those components can be:
>> - Commons RNG (Random Number Generators)
>> - Commons Complex (Complex Numbers)
>> - Commons Matrix (Matrix Algebra)
>>
>> Those components might have an own life, those algorithms have a wide
>> audience and can be used in a lot of stuff on its own. The question is
>> what happens with:
>> - Commons Genetics (Genetic Algorithms)
>> - Commons ML (Machine Learning)
>
> If there is a case to be made to move components out of Commons Math to
> become individual Commons components then those proposals should be made
> individually so the merits can be discussed.
And it has to be cleared what it means for CM itself.
> For example, just by its name
> I am not sure why Machine Learning belongs in Math unless it really is
> just a bunch of machine learning algorithms.
It seems so.
>> Or other stuff requiring deep mathematical background. I don't have the
>> impression this belongs as own components into Commons. Moving CM as
>> whole into a new TLP at least provides a place for all of it.
>>
>> The question is, what do we want as PMC members?
>
> I\u2019m not sure I understand the question.
Do we want new individual components here in Commons that have been
extracted from the original CM? Basically this could be done for some code
(targeting a wide audience as explained above), but the rest of the code
will no longer fit even as individual components into the Commons context.
And what are the consequences for CM if we go down that road.
> Once there are enough active
> committers then I would think they would become Math TLP PMC members when
> it is appropriate.
To me this means to keep CM alive as it is (multi-project or not), wait for
a big enough community (in the incubator or here) to claim TLP and the Math
TLP can then act with the code as it likes.
- J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache, commons, math
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Jun 19, 2016, at 10:40 AM, Jörg Schaible <jo...@gmx.de> wrote:
>
> Hi Ralph,
>
> Ralph Goers wrote:
>
>> Thanks, Eric.
>>
>> I am OK with Commons Math being split into modules in the Commons Math
>> sub-project.
>
>
> That was my first idea too. But if the collection of all submodules will in
> the end nevertheless only contain 20% of the code, we gained nothing.
>
>
>> 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.
>
>
> The main problem seems to be that CM was a dumping ground for all kind of
> stuff that have at least the slightest relation to a mathematical base.
>
> Gilles never expressed it directly, but in its consequence he proposed to
> move the current CM into dormant/attic and extract single parts of the old
> code base as new components.
Personally, I don’t think moving it to the attic is appropriate. Projects go to the attic, not components. The Math project (or sub-project) is free to add or drop components as the see fit, so long as it is a community decision.
>
> Some of those components can be:
> - Commons RNG (Random Number Generators)
> - Commons Complex (Complex Numbers)
> - Commons Matrix (Matrix Algebra)
>
> Those components might have an own life, those algorithms have a wide
> audience and can be used in a lot of stuff on its own. The question is what
> happens with:
> - Commons Genetics (Genetic Algorithms)
> - Commons ML (Machine Learning)
If there is a case to be made to move components out of Commons Math to become individual Commons components then those proposals should be made individually so the merits can be discussed. For example, just by its name I am not sure why Machine Learning belongs in Math unless it really is just a bunch of machine learning algorithms.
>
> Or other stuff requiring deep mathematical background. I don't have the
> impression this belongs as own components into Commons. Moving CM as whole
> into a new TLP at least provides a place for all of it.
>
> The question is, what do we want as PMC members?
I’m not sure I understand the question. Once there are enough active committers then I would think they would become Math TLP PMC members when it is appropriate.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache, commons, math
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 19 Jun 2016 19:40:34 +0200, J�rg Schaible wrote:
> Hi Ralph,
>
> Ralph Goers wrote:
>
>> Thanks, Eric.
>>
>> I am OK with Commons Math being split into modules in the Commons
>> Math
>> sub-project.
>
>
> That was my first idea too. But if the collection of all submodules
> will in
> the end nevertheless only contain 20% of the code, we gained nothing.
>
>
>> 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.
>
>
> The main problem seems to be that CM was a dumping ground for all
> kind of
> stuff that have at least the slightest relation to a mathematical
> base.
>
> Gilles never expressed it directly, but in its consequence he
> proposed to
> move the current CM into dormant/attic and extract single parts of
> the old
> code base as new components.
Really?
I have a hard time figuring out what could have been more direct than
the initial post of that thread:
http://markmail.org/message/ye6wvqvlvnqe4qrp
>
> Some of those components can be:
> - Commons RNG (Random Number Generators)
> - Commons Complex (Complex Numbers)
> - Commons Matrix (Matrix Algebra)
>
> Those components might have an own life, those algorithms have a wide
> audience and can be used in a lot of stuff on its own. The question
> is what
> happens with:
> - Commons Genetics (Genetic Algorithms)
> - Commons ML (Machine Learning)
>
> Or other stuff requiring deep mathematical background. I don't have
> the
> impression this belongs as own components into Commons. Moving CM as
> whole
> into a new TLP at least provides a place for all of it.
>
> The question is, what do we want as PMC members?
>
>
>> 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\u2019t 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.
>
>
> And this does not require that the code base is separated now before
> the
> decisions are made.
>
>
>> IMO, that community needs to be of sufficient size that it
>> is somewhat representative of the users of Commons Math. That
>> doesn\u2019t mean
>> it necessarily needs 10 people, but I would say it needs more than
>> 2.
>
>
> Otherwise a TLP will never be accepted.
>
>
>> 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\u2019t
>> \u201cincubate\u201d here in Commons).
>
>
> +1
>
> Thanks for your thoughts, Eric + Ralph!
>
> - J�rg
>
>
> ---------------------------------------------------------------------
> 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
Re: apache, commons, math
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote:
> Thanks, Eric.
>
> I am OK with Commons Math being split into modules in the Commons Math
> sub-project.
That was my first idea too. But if the collection of all submodules will in
the end nevertheless only contain 20% of the code, we gained nothing.
> 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.
The main problem seems to be that CM was a dumping ground for all kind of
stuff that have at least the slightest relation to a mathematical base.
Gilles never expressed it directly, but in its consequence he proposed to
move the current CM into dormant/attic and extract single parts of the old
code base as new components.
Some of those components can be:
- Commons RNG (Random Number Generators)
- Commons Complex (Complex Numbers)
- Commons Matrix (Matrix Algebra)
Those components might have an own life, those algorithms have a wide
audience and can be used in a lot of stuff on its own. The question is what
happens with:
- Commons Genetics (Genetic Algorithms)
- Commons ML (Machine Learning)
Or other stuff requiring deep mathematical background. I don't have the
impression this belongs as own components into Commons. Moving CM as whole
into a new TLP at least provides a place for all of it.
The question is, what do we want as PMC members?
> 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\u2019t 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.
And this does not require that the code base is separated now before the
decisions are made.
> IMO, that community needs to be of sufficient size that it
> is somewhat representative of the users of Commons Math. That doesn\u2019t mean
> it necessarily needs 10 people, but I would say it needs more than 2.
Otherwise a TLP will never be accepted.
> 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\u2019t
> \u201cincubate\u201d here in Commons).
+1
Thanks for your thoughts, Eric + Ralph!
- J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: apache, commons, math
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks Eric for your view and great suggestions!
I agree that more Commons-like codes that are easy enough to understand fit
well here, and that more exotic interpolators etc are harder to get into,
and would fit better in a mathematician-centric community
(Incubator/TLP/Github organisation) with more leverage as to breaking API
changes and different release granularities. I think if we start
categorizing it could be difficult to draw the line, but I think Gilles "I
can (roughly) understand this" is a good criteria to start with.
I think it's OK for Commons Maths +1 to have less features, particularly
here we know Maths have grown too big. It's possible to later re-add your
favourite algorithm, so the documentation would need to clearly show both
the ("unsupported") legacy version and the newer more focused version.
However I still don't understand the reluctance to release "unsupported
code" - we have no support contracts or correctness guarantees. If say
AkimaSpline Interpolator has already been released, then why can't it be
included in future releases? Any bugs from before would be the same later.
I know from experience that it's annoying when repeated updates to open
source software haven't fixed your most annoying bug; but then this itch is
what can trigger a "perhaps I can fix it then?" reaction.
I have not explored the differences, but if it is the case that the master
branch have too much experimental code which has never been released and
which you don't want to commit to "supporting", how about putting them in
an .experimental package? It would be a good indicator that you're on your
own, this might break, please come join us to develop these further.
If someone finds a bug they care enough about, then perhaps we need to
reevaluate why they can't simply contribute a fix (e.g. reluctance to
degrade performance) and lower the barriers for becoming part of Math -
this is important both inside or outside Commons. We don't need to verify
the absolute correctness of the fix; we should rather assume by default the
contributor who needs a fix in a particular specific method knows something
about its algorithm and try to bring in their knowledge (and hopefully
future maintainership).
I think we need to keep calm and avoid rushing off with arguments and he
said/she said; we don't need to fragment the Math community any further and
be realistic with what is a reasonable code base to work with for a
smaller/fresher community. I think it's clear that such a community would
need some liberty to decide for itself on things like release and update
policies and how to structure/modularize it's code, and I think the
Incubator would be a good place to try this out. (If it doesn't work out,
that is also OK)
I think it's also important for us to revisit the assumed requirement of
all classes to remain "supported", I can tell you there are many Apache
projects that have effectively unsupported modules or packages (stagnant
development, lack of knowledge within active committers), but they are part
of the regular releases and therefore still are supported in the sense that
they still compile and can accept patches.
On 19 Jun 2016 12:09 a.m., "Ralph Goers" <ra...@dslextreme.com> wrote:
> 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 <er...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: apache, commons, math
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <er...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org