I agree with Jörg's email below. Furthermore, to me, the best chance [math] has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to stay in Commons in its current single module form (KISS) _because_ a bunch of [math] developer's have left. We have a bunch of people in Commons that are smart and _can_ fix _some_ of the problems, can _shepherd_ patches, and _mentor_ newcomers; all of which could not happen in a new TLP unless all Commons committers came along.
$2 (inflation) Gary On Fri, Jun 10, 2016 at 3:19 AM, Jörg Schaible < joerg.schai...@bpm-inspire.com> wrote: > 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
