I'm another Commons developer who: * Hasn't been "present" lately * Has no special mathematical background * Desires consensus * Repeatedly reads these exchanges in a state of vacillation between sympathy for Gilles's situation and suspicion that his communication style is too abrasive. Ultimately, I get that you're frustrated.
I too have felt all along that Maven modules would be an acceptable approach wrt CM, but my view (in which I am seemingly not alone) of that set of code as "alike" simply because it relates to mathematics is, as I imply above, very likely rooted in ignorance. At the same time, the field of software development is only hoped to become more accessible by those with decreasing amounts of formal education, so perhaps it is fair that the line be drawn in the interest of the mathematical outsider. Even I have a reasonable understanding of basic geometry and can appreciate that there may be more situations in which its use would be "common." On the other hand, it still clearly feels like I would expect to find that among "math" code. As Ray has pointed out, there is no *technical* reason a Maven project's submodules must have synchronized release schedule or version numbers. It would seem to me that his approach, perhaps accounting for the notion of the "legacy" submodule, while undeniably increasing complexity of management to some extent, still seems the most likely way forward to give all parties *enough* satisfaction. We are developers: we should be able to create tooling, e.g. in Jenkins or elsewhere, that could help manage the coordination of version numbers between parent and children. In any case, Gilles's statement that geometry represents the outer edge of his vision for CM expansion means that this discussion needed to take place soon anyway; the only remaining decisions should IMO be 1) whether geometry belongs with CM5, and 2) whether numbers should be reabsorbed into such a CM5 structure. Matt On Sep 10, 2017 11:35, "Raymond DeCampo" <r...@decampo.org> wrote: I know I haven't been around lately, but I this exchange caught my eye. I was trying to figure out a way to balance the issues, first, that there is resistance to creating a large number of projects spun out from CM and second, that there is a practical limit to how large a project can be maintained with the current resources. What I came up with is as follows: suppose we take CM and split it up into a number of modules. Then within the project we treat each module independently for the purposes of maintenance, release etc. So that if the geometry module is ready to cut a new release it may do so without being held up by issues in the other modules. So, how to accomplish this and still have CM appear to be and behave like one project? Each module would have it's own development branch. In the master branch would be a copy of the last released version of each module. Development happens in the development branch. When a module is ready to release, it merges into the master branch, bumps the version and releases the whole thing (i.e. all of CM). So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module and 4.2.8 of the geometry module. The geometry module is ready to make a new release, so it merges into master and bumps CM to 4.3.6 and geometry to 4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the same as 4.3.5 except for the geometry module, which is now at 4.2.9. While working this out I took a stab at splitting CM into modules. I ran into issues with the stats & distribution packages as many of the tests for other classes depend on them. So there's some work there to detangle some of the packages. But I was able to split out geometry, transform, optimizers, filter, diffeq and machine learning without a lot of trouble. See https://github.com/RayDeCampo/commons-math/tree/modules if you are interested. On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 4/09/2017 à 15:30, Gilles a écrit : > > > I see it as a fundamental one: Why should codes unrelated > > by scope be artificially tied together by management rules > > (such as design, supported language version, release schedule, > > etc.)?[1] > > Because they share the same general scope of being math related. The > design and the supported language version can be different for each module. > > > > Why do you "prefer" multi-module, independently of the subject > > matters being talked about? > > I already explained twice in this thread. > > > > Please comment on my suggestion to create a single maven project > > for the whole of "Commons". I'd agree that this suggestion is > > ridiculous; yet some of you do the same proposal for "everything > > math-related". > > If you want to use an absurd proposal to prove your point let me try > that game too: Please comment on my suggestion to create multiple > components out of every Java package defined in the Commons components. > > > > If you had been contributing to the math codes (plural), you > > perhaps would have understood that it creates more management > > problems than it solves.[4] > > Please use foot references for external links only, your messages are > unreadable if we have to go back and forth to understand them. > > > > Again, I have to stress on what happened that led me to propose > > a new "Commons RNG": obvious improvements to the CM code base > > were outrightly rejected based on demonstrably false statements; > > i.e. the objections were not technical but for the convenience > > of one user. > > I still think that splitting RNG into its own component was a good move. > I'm less happy with Numbers, I'd have preferred a module from a > renovated "CM5" project started from scratch as I'm suggesting now for > Geometry. > > > > Do you think that I enjoy contradicting you on these matters? > > I'm starting to think that you enjoy rhetoric, probably more than > seeking compromise unfortunately. > > > > Do they want to implement another plan? What plan? > > Here is my counter-proposal: > > 1. Refactor Commons Math as a multi-module project, bump to version 5 > 2. Create two modules: geometry and legacy > 3. Release Commons Math 5, without the legacy module > 4. Spin-off new modules from the legacy module when needed > > And I'm willing to help at least for the steps 1 and 2. > > Emmanuel Bourg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
