Hi Gilles, That sounds eminently sensible to me as an end user. I'd like my 3rd party deps to be as small as possible, so a modularised Math is good for me.
Cheers, Martijn On 7 December 2017 at 17:05, Gilles <gil...@harfang.homelinux.org> wrote: > Hi Martijn. > > On Tue, 5 Dec 2017 23:45:43 +0000, Martijn Verburg wrote: > >> Can this project be forked to a new domain over on GitHub (under the >> existing Apache license), >> > > It is allowed, of course. However, I think that it is the > last option to consider, because it will further dilute the > community that has an interest in the "Commons Math" codebase. > For developers and for users, there are practical advantages > in keeping the spin-off projects within "Commons". > It is even a more appropriate place than a TLP! > [In this evaluation, I of course do not account for the > negative stance of part of the PMC.] > > split up and then continued in that case? >> > > The work had started. > Did you have a look at "Commons RNG"[1] and "Commons Numbers"[2]? > Both were spun off the development version of "Commons Math"[3]. > > IMO, current priority is to have an initial (beta?) release of > "Commons Numbers". There is a list of issues in the bug-tracking > system: > https://issues.apache.org/jira/projects/NUMBERS > > An important test must pass (before a release can make sense): > All the code that was "moved" (to "Numbers") must be removed > from "Math", and functionalities of the latter must be adapted > to depend on "Numbers". > > Afterwards, a probably easy task would be to create another > generally useful component out of the "o.a.c.math4.geometry" > package (no other part of CM depends on it and it has almost > no dependencies on any other CM class). > Another easy move would be the code in package "o.a.c.math4.ml" > (zero cross-dependencies). [Although developer and user of that > package, I admit that the functionality might currently be too > limited to warrant a component.] > Less easy (but quite useful) would be a component based on a > selection of the functionalities in package "o.a.c.math4.analysis" > (root solver, interpolation, integration). > > The rest of CM is either too advanced or with cross-dependencies > not easy to untangle and/or too many issues to solve, in order > to create good components, given the scarce human resources... > > Next, we can tackle tasks on CM itself: > - make modules for functionality that is free of issues and > supported, and > - make a "legacy" module for everything else. > Then, we head toward a long-overdue release. > > Opinions on the plan is appreciated, and help to make progress > (forward!) is most welcome. > > Regards, > Gilles > > [1] https://git1-us-west.apache.org/repos/asf?p=commons-rng.git > [2] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git > [3] https://git1-us-west.apache.org/repos/asf?p=commons-math.git > > >> Cheers, >> Martijn >> >> On 3 December 2017 at 11:51, Gilles <gil...@harfang.homelinux.org> wrote: >> >> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote: >>> >>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>> There hasn't been any progress towards a decision. >>>> >>>>> There isn't even a consensus on one of the central tenets of >>>>> Apache ("Those who do the work..."): how sad/strange (?). >>>>> >>>>> >>>> Those who do the work are welcome to decide on their own, if they do >>>> not involve others. >>>> >>>> >>> The conditional is not part of the well-known mantra. >>> >>> The issue here is to answer the question of what to do with >>> a non-trivial code base. My stance is to try and fix the >>> problem(s), a.o. difficult management, by rooting out its >>> main cause: CM has become an aggregate of components with >>> completely different subject matters, scopes, designs, >>> efficiencies, provisions for extension, etc. >>> [An array of issues which "maven" modules will not solve.] >>> >>> We are seemingly faced with a choice between: >>> 1. Maintain CM as the huge library that it is now. >>> 2. Incrementally create maintainable components. >>> >>> A long time has passed since these alternatives were first >>> exposed, only proving that none of the people who informally >>> chose option(1) invested work to make it a reality. >>> >>> Refusing option (2) not only "involves others"; it is harming >>> them (very real people, having done a lot of work here, on >>> that code base). >>> >>> Establishing a new commons component doesn't >>> >>>> qualify, IMO. >>>> >>>> >>> True; that's why we are stalled, despite that a majority >>> of the PMC did not explicitly oppose option (2). >>> >>> A handful of PMC people prefer to let the code base become >>> "dormant" rather than give any chance to an alternate view. >>> [If, say, you looked at the "Commons RNG" project, and >>> concluded that, decidedly, this is not how a component >>> should look like, then I could perhaps fathom out where >>> those reservations come from.] >>> >>> Gilles >>> >>> >>> Jochen >>>> >>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
