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
