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" <[email protected]> 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 <[email protected]>
> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
