Hello.
Le ven. 14 juil. 2023 à 16:15, Dimitrios Efthymiou
a écrit :
>
> Hello devs. I need a little help.
>
> 1--Say that I want to implement a new feature/function that, technically
> exists in the math4 or legacy, but it doesn't exist in commons- geometry or
> commons- numbers. What is the protocol? Do we create a ticket on math4 and
> put the new code in math4 and ignore the geometry/numbers projects?
If it's in the [Math] component, but some rationale can be found that it
should be in one of the other (newer) components ([RNG], [Geometry],
[Numbers], [Statistics]), then it should be ported there (once done, the
functionality is removed from [Math]).
The underlying principle is that the newer components are more
focused (than [Math]), so that a contributor interested in that subject
matter is more likely to be able to help clean up all the issues that block
the next release
As you can see, there are many long-standing issues in [Math] because
it covers many subjects, and no one is sufficiently interested in everything
(or has enough time) to do the necessary refactoring.
If the feature is in "legacy", but is part of larger "subject matter" which a
refactoring could implement in a modular way (reducing dependencies
and removing circular ones), the new package should be moved to a
(maven) module of its own. [That has been done already for several
packages for which it was relatively straightforward (because they were
not involved in circular dependencies).]
As I've already suggested, the next task on that list would be to refactor,
fix and move the "clustering" functionality (adding documentation, and
JMH benchmarks along the way).
Another pending task is the refactoring of the "genetics" package. [See
the associated JIRA reports. There is also a long ML thread about it (cf.
"dev" ML archive).]
>
> 2--Can contributors remove code from math4 and move it to the other new
> math projects?
Sure.
In practice, we can do it now because we released a "beta" version of 4.0;
hence we allow ourselves to break compatibility until the a non-beta version
is released.
> I see in GitHub for commons-math it says: "Functionality
> still within "Commons Math" is gradually being modularized and refactored".
> Is there documentation that explains the precise way math4 should be
> refactored and modularised and who is allowed to even touch math4 and move
> functionality out of the library?
You can do whatever you want with your copy/clone of the repository.
Of course, as you noticed, the issue is to have a committer agree to
merge your changes back to the ASF's copy.
Prior discussion avoids people doing useless work (although sometimes,
no agreement could be found a priori, yet a developer might wish to do
the work anyway; that's how the [RNG] component got started).
>
> 3–Are the math-related projects (like numbers and geometry) final?
The math-related (so called because they were initially comprising
refactored code ported from [Math]) components are
* [RNG] (main maintainer: Alex)
* [Numbers] (main maintainer: Alex)
* [Statistics] (main maintainer: Alex)
* [Geometry] (main maintainer: Matt)
The PMC did not agree to create more [Math] spin-offs.
So, the second best option was to modularize [Math]. Perhaps in
the future, some modules will grow sufficiently so as to be worthy
of their own component...
> For
> example, where is calculus gonna go?
In a module within [Math] (provided it does not enter in a dependency
loop with other modules).
> Is there gonna be a new project like
> commons-calculus? Same question for other math theories.
Currently: No (reason given above).
>
> 4--Are the submodules of the numbers and geometry projects final? Geometry
> has the commons-geometry-euclidean module and a few more. Will there be new
> modules added to the math-related projects, as time passes?
Sure (by definition, it's the goal of modularization), as long as the
new modules stay within the component's scope.
Of course, there are practical conditions to creating a new module.
Some are pretty straightforward: Thorough documentation, same
programming style as the rest of the code base, full coverage by
(Junit) unit tests, JMH benchmarks (if departing from an existing
implementation).
Some are more vague, like avoiding that the component becomes
the receptacle of code which no one wants to maintain.
Regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
