On 01/17/2016 02:34 PM, Gilles wrote: > On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote: >> Le 16/01/2016 16:51, Gilles a écrit : >>> Hi. >>> >>> Context: nobody gave an opinion on the arguments which I put >>> forward in these posts: >>> http://markmail.org/message/uiljlf63uucnfyy2 >>> http://markmail.org/message/ifwuijbgjytne6w2 >>> >>> As a consequence, the lack of any development policy, rather >>> than being the touted advantage of the "free world" of Apache, >>> is, objectively, a quite efficient way to push in the direction >>> of the stronger voice, not necessarily backed with the stronger >>> arguments (especially when those are not "technical" but, in >>> reality, "political"!). >>> This has been the subject of another post, that also was not >>> followed by a constructive debate in order to change this >>> community's ways, so that it would not discourage proposals >>> for code evolutions towards a modern use of the Java language. >>> >>> Thus, in this context, I obviously can't know whether "silence >>> is consent" or if people will continue raising objections to my >>> experimenting with the contents of the "random" package, even >>> after not raising concern and/or not engaging in the practical >>> discussions about the proposals. >>> >>> Also, it is disrespectful to let people think that they could >>> work on some part of the library, and then voice an opinion >>> akin to the hidden policy that there exists, in CM, codes >>> that are deemed too sensitive to be ever touched again. >>> >>> My first idea was to make incremental changes in "random". >>> The first few, and little, steps unexpectedly implied a huge >>> amount of work, mainly due to the disproportionate >>> justifications that were being required. >>> >>> It is a fact that even tiny, even no-op, changes meet >>> infinitely more opposition than adding even very large chunks >>> of new code. >>> >>> Hence, I propose that all my recent changes to the "random" >>> package be reverted so that it will match the contents of the >>> 3.6 release (modulo the changes which were explicitly agreed >>> on like those in "RandomGeneratorAbstractTest"). >> >> I did answer to at least part of your proposals, and suggested >> this experimentation is done on a branch. >> At the same time, you also proposed to adopt another branching >> policy, and this was seen positively by anyone. >> >> So I would suggest that rather than adding a parallel rng package, >> which reminds me of the difficulties we get with the two optim and >> optimization packages, you continue doing your changes directly >> in the random package as you started to do, but in a feature branch. > > Sorry, but I don't agree. > I've explained that I want to propose as a *replacement* to "random". > Almost every file will be changed, and a basic requirement is to have > the RNGs, and only the RNGs, in their own package/module. > > So for example, "RandomDataGenerator" and "ValueServer", as "users" > of the RNGs, should not be in the "rng" package (but but stay in > "random" whatever else changed or delete there). > > This situation here cannot be more different than for the "optim" > package! > First, the old "optimization" _has_ been deleted in "master"; we > had to keep it in the 3.x line. > The code in "optim" has been been criticized but until now nobody > came up with a better proposal, so the only working code must > obviously stay.
Afaicr we all agreed on going forward with the design as implemented for the least-squares optimizer by Evan? Thomas > For "rng", I'll propose a working remplacement, and we'll be able > to immediately decide whether to keep "random" as is or adapt it > in order to remove the redundancy with the new "rng" and/or write > some adaptation layers from "random" to "rng". > > Best regards, > Gilles > >>> >>> Is that possible? [Luc, as the most experienced "git" user, >>> would you mind managing this, perhaps delicate, operation?] >> >> Reverting is not difficult. Remember the trick discussed on >> this list to port commits between math3 and math4? It was >> basically doing a "git diff -p some-commit~1 some-commit", >> then patching the commit with a sed and applying it later on. >> >> Here is it even simpler because we don't have to patch the commit. >> The trick is to do the git diff the other way round, i.e. >> "git diff -p some-commit some-commit~1". >> >> Also rather than reverting them and restarting again, in >> order not to lose your work I'll cut a new feature branch >> first, then revert on master only. You will be able to >> continue your work on the feature branch. >> >> On a related subject, I also read on another list that infra >> now allows deleting branches again. The concerns I had with >> short-lived hotfix branches are therefore not realistic >> anymore, we can do as many brnahces and as short-lived as we want. >> >>> >>> I would then pursue my refactoring in a new package named >>> org.apache.commons.math4.rng >>> where all the modifications, that led to the latest outburst of >>> conservatism, will take place. >>> It will also allow me to further experiment and see where it >>> leads, without having to argue endlessly on every compatibility >>> breaking. >>> >>> In effect, it's a fork of "random" (but within CM). >>> Of course, this will happen in a "feature branch" which I'll >>> create upstream when the renaming has been performed. >>> >>> Then people can see both sets of codes "side-by-side", analyze >>> them, experiment with usage, and run benchmarks of the alternative >>> versions of the RNG classes. >>> >>> Ultimately, if the rift between conservatists and modernists >>> remains, both the "random" and the "rng" packages can coexist >>> in the 4.0 release of the library. >> >> I would really prefer not to live again the >> optim/optimization/least squares nightmare. >> >> best regards, >> Luc >> >>> >>> >>> Regards, >>> Gilles > > > --------------------------------------------------------------------- > 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
