As someone relatively new to the project, I feel like my statement here may have a little weight. First, I do really want to help in whatever capacity I am able (given that I’m a tad over-run currently with a new[ish] 2-month-old baby). That said, I am perfectly willing to contribute in whatever direction folks decide to go.
Pardon for my potentially restating the obvious, but it seems to me that the three main contributors to the project have split off because of what they see as headaches in the fact that they were necessarily coupled to Apache Commons. Meanwhile, we sit with the code they decided to leave. Now the two questions standing in my mind are: what will the user base do, and what will the Hipparchus folks do if the project was indeed TLP’d? If I had to guess at the the first, people using the library may tend towards sticking with commons-math simply because it is housed by Apache. Further, I would guess, maybe naively through, that without the Apache “brand” Hipparchus may have difficulty gaining traction. On the second question, I would hope that if we did TLP the project that the Hipparchus folks would return to assist, but maybe they find it free-er out there in the “wide open air." With that all in mind, my thought might be to do something like try to get out 3.7 and 3.8, while in parallel trying to jump through the requisite hoops to become a TLP hoping that more folks hop on board. Just the thoughts running through my mind, and I my plan is to be willing to help regardless of direction. Hope that helps, -Rob > On Jun 10, 2016, at 6:55 PM, Gilles <gil...@harfang.homelinux.org> wrote: > > Hi Patrick, and others. > > On Fri, 10 Jun 2016 07:37:00 -0400, Patrick Meyer wrote: >> I think it would be better to spend the time trying to recruit new >> contributors than it would be to alienate existing ones. > > By what are you alienated? > [This is addressed to all readers and would-be contributors to > the Commons project.] > > Are there, among the readers, people who'd step forward to take > all the CM codebase, and start the process towards a TLP? > > Are there people, among the CM contributors (or willing to > contribute) opposed to having the "Random Number Generator" > functionality being split off of the CM codebase. > > Are there people opposed to the same concerning the functionality > based around the complex numbers? > > Are there people opposed to the refactoring of the "o.a.c.m.ml" > package (which is likely to break all applications currently > using it)? > >> Also, the >> effort required to divide the library into smaller parts > > In some cases, the effort is worth it. > In the first case I want to submit (RNG), the effort was done already; > and for that reason also (in addition to the objective bonuses), I want > to see this code released sooner than later (or never). > >> would be >> better spent creating patches. > > Patches welcome. ;-) > >> Does anyone have ideas for actively recruiting contributors? > > Contributors will (maybe) come to a project they like; as noted > by others, they (certainly) won't come where there is no fun. > > Then some people come and ask: "What is the roadmap?". There was > none. It was impossible because of the unlimited scope, the > lack of resources, the wildly different priorities, etc. > >> Do you >> know of mathematics departments that also teach students Java >> programming? A recruiting campaign with the message like "here's what >> we do at CM, we'd like your help" could attract new contributors. > > What do we do? > Let's see the actual message. > > I am well placed to remind that CM as it was "practiced" did not > attract many people. [At a talk (FOSDEM), four years ago, one of the > questions was about the Java version; we were well into the Java 7 > era; a telling silence followed Thomas Neidhart's answer that the > "consensus" was to stick to... Java 5. From an audience of more than > 60 people, zero contributor.] > >> It >> will take time, but a constructive approach like this one will do more >> to sustain CM. > > This is something to explore. Are you going to do it? > > How are you so sure that "it will do more" that what I propose, > which is in fact quite constructive. > > I understand that you may be angry by this long chain of mails. > But please do not shoot at the bearer of bad news. > > Regards, > Gilles > >> Thanks, >> Patrick >> >> -----Original Message----- >> From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com] >> Sent: Friday, June 10, 2016 6:20 AM >> To: dev@commons.apache.org >> Subject: Re: [Math] Commons Math (r)evolution >> >> Hi Gilles, >> >> Gilles wrote: >> >>> Hi. >>> >>> On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote: >> >> [snip] >> >>>> MATH-172 is about an enhancement. Unfortunately no-one can currently >>>> implement it, so we have to wait until someone can or the issue stays >>>> simply unresolved again. You've requested for help and that was the >>>> proper action. >>>> However, there has been no problem to release 3.0 in this state, so >>>> why should it be a problem now for 4.0? >>> >>> Because the context has changed: in 3.0 there was support, now there >>> isn't. >> >> >> That does not state the fact, that the code is already released and >> it does not matter at all if users ask questions for release 3.0 or >> 4.0. >> >> >>>> MATH-1735 is a bug report for a problem which is currently not >>>> reproducible. >>>> Again you did the right action, but without more input and without a >>>> possibility to reproduce the problem, there's not much we can do. >>>> Again, why >>>> should this issue prevent a release of 4.0? >>> >>> The code in question should not have been in CM. [That was my position >>> back >>> then (cf. archive).] >> >> >> Again, you cannot change history, it is already released. And a new release >> of the code does not make the situation worse. >> >> >>> And every bug report for it is a reminder that unmaintainable code >>> should >>> not be released. >> >> >> That is your interpretation. For me it is a normal bug report and we can >> eigher solve it on our own or have to wait for a contribution. >> >> >>>>> Moreover what could be true for VFS is not for CM where there are >>>>> many, >>>>> many different areas that have nothing in common (except perhaps >>>>> some >>>>> ubiquitous very-low utilities which might be worth their own >>>>> component >>>>> to serve as a, maybe "internal", dependency). >>>>> >>>>> Also, compare the source basic statistics (lines of code): >>>>> VFS CM >>>>> Java code 24215 90834 >>>>> Unit tests 8926 95595 >>>>> >>>>> All in all, CM is more than 5 times larger than VFS (not even >>>>> counting >>>>> documentation). >>>> >>>> Any why is size suddenly a problem? >>> >>> Not suddenly. >>> I've raised this issue for years. Please look at the archives! >> >> >> Then: Why is size a problem? It is only a problem if *you* try to support >> all of it at once. Nobody expects that. >> >> [snip] >> >> >>>> Fine. But talk about artifacts, not components. Apache Commons Math >>>> is still >>>> *one* component of Apache Commons. It does not matter if you divide >>>> the code >>>> into different artifacts as long as anything is released together. >>> >>> I know. >>> >>> What you can't seem to get to is that I consider it a bad idea to >>> release >>> unsupported code. >> >> >> You've stated that multiple times now. >> >> >>> I think that "I do not know (and nobody else does)" is not an >>> acceptable >>> answer to user requests. >> >> >> See, this is the difference. To me this *is* acceptible. Especially if users >> have to be kind of experts themselves to use this code. >> >> >>> If we _know_ that some parts of the code would be unsupported (such >>> that it >>> would elicit this kind of answer for bug reports), then it's >>> _deceiving_ to >>> release that code. >> >> >> A new release does not change the situation at all. With such a definition >> we could move quite some of our components directly to the attic, because >> the original authors are no longer around and we might currently have no >> expert around. >> >> >>>> Individual release cycles for the different parts can only happen if >>>> Math is >>>> TLP, but not in Apache Commons. We will certainly not allow and >>>> create again >>>> any sub-umbrellas (search the Jakarta archives). >>> >>> Who talked about sub-umbrellas? I didn't. >> >> >> I talk about it, because it is what the result looks to me. >> >> >>> I've explained that >>> 1. CM cannot be released as it was before >> >> >> You've expressed that *you* don't want to release it as it was before (well- >> founded however). >> >> >>> 2. for some parts, the necessary _minimal_ support has "disappeared" >> >> >> That does not immediately invalidate the existing code. One fact that you >> don't want to see. >> >> >>> 3. some parts can be turned into independent components (with _full_ >>> support) >> >> >> Have we some kind of agreement here to introduce new Commons components? As >> far as I know, we just did not oppose to break Math into individual >> artifacts. >> >> >>> 4. Some people are ready to perform the necessary steps in order to >>> create these components >> >> >> The work on the code is still independent of a monolithic Math component vs. >> inidividual (let's say) Maven projects. The refactoring is the same if you >> simply want to minimize the dependencies between the Java packages in Math. >> >> >>> Please comment on how this contradicts Commons policy. >> >> >> The ASF in general does not like umbrella TLPs at all. Apache Commons >> actually has been near this category all the times. We try to manage a >> (large) set of general purpose libraries with the intent to provide long >> time compatibility (sometimes possibly exaggerated) or provide clear upgrade >> paths if a redesign was necessary. We do this, because we are aware that our >> components are nearly always part of large software stacks and we may impact >> a lot of stuff if we fail. >> >> However every of our components has a general purpose. Math is described as >> "Lightweight, self-contained mathematics and statistics components". The >> component in its completeness is certainly no longer lightwight. >> >> What you propose now, is to move Math in its current state into dormant (or >> even attic, because it will then never be revived in its current state) and >> create several (how many?) new Commons components, all of them focussed to a >> special mathematical problem. And this is exactly the reason why a bunch of >> new Math components no longer fit into Commons, because they fail the >> "general purpose". >> >> It has happened before that a Commons component had outgrown the general >> purpose (see former HttpClient that is now a successful TLP) and Math might >> be not the last one. Remember, we already had a successful vote for a Math >> TLP this year for exactly these reasons. >> >> [snip] >> >> >>>> What you talk about is a complete new component without a proper >>>> upgrade >>>> path for users of Math 3.x. >>> >>> "Commons Math" is a dead end. Is it that which you did not get? >> >> >> It's death when we decide it together. Currently it's your (well-founded) >> opinion. >> >> >>> There is "Commons" and there are "math codes" implementing various >>> functionalities, some in good shape, which I want to help release, >>> some in bad shape (for numerous reasons which you don't know about >>> and don't seem to want to hear about) which I'm not going to help >>> release as long as they are in that state. >>> >>>> You wanna use the new stuff for complex numbers? >>>> Well, adjust your code to the new structures in >>>> commons-math-complex-4.0. >>> >>> No. It should be "commons-complex-numbers-1.0" (or perhaps "0.1" if >>> that's allowed). >> >> >> See, I doubt that all devs were aware of the fact, that we're currently not >> just talking about a Math component with multiple artifacts, but a bunch of >> new Commons components instead (discontinuing the "Math component"). >> >> >>>> Oh, you also want to use genetic algorithms?, Well, that part of the >>>> code >>>> should stick with commons-math-3.0, because we did not took it over >>>> for 4.0. >>>> Maybe for 4.1 ... >>>> >>>> Sorry, but for such a release I already propose my vote today: -1 >>> >>> So you prefer to sink whole work rather than be pragmatic about the >>> new reality. >> >> >> As PMC I care for a sane Commons community with already ~40 maintained >> components. >> >> >>> How is that preferable to the user community? >> >> >> And what does the name "commons-complex-numbers-0.1" vs. "commons-math- >> complex-number-4.0" change for the users' situation I've described above? >> >> >>>> In that case I'd move Math really into the incubator. >>> >>> Please do. >>> >>> There are several options: >>> 1. Go on with a monolithic Commons Math >>> 2. Break the codebase into (maven) modules >> >> >> Concerning the release cycle, there's no difference between 1 and 2. >> >> >>> 3. Create (in the long term) an all-encompassing TLP >>> 4. Create reusable components (right now) >> >> >> IMHO, 4 is not an option for Commons, only for a Math TLP. Which needs an >> own community. Which has to be rebuilt. >> >> >>> [Add others if appropriate.] >>> >>> Which is more useful, in your opinion? >> >> >> As stated above. >> >> >>> To which are you going to contribute (multiple choice allowed, >>> of course)? >> >> >> Nowadays I typically care for the release only. And I care for the impact of >> it, because my software stack is also built upon Commons. >> >> Cheers, >> Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
