Hello. Le ven. 14 juil. 2023 à 16:15, Dimitrios Efthymiou <efthymiou.dimitri...@gmail.com> 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
