On 1/17/16 9:33 AM, Luc Maisonobe wrote: > Le 17/01/2016 16:31, Phil Steitz a écrit : >> On 1/17/16 6:34 AM, 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. >>> >>> 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". >> +1 to separate the PRNG abstract class(es)? and impls into a >> separate package called "rng." I would personally favor making that >> a subpackage of random. > OK. Then we can simply delete the current random-revamp branch. > Anyway, cutting the branch before the revert was an error from > a git point of view. It would have created lots of conflicts > on the merge operation. So if a random-revamp branch is > really used, it should rather be cut again from the current > master. > > Do you agree that I delete this ill-formed random-revamp branch, > which currently has no commits at all?
+1 Phil > > best regards > Luc > >> Phil >>> 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 >> >> > > --------------------------------------------------------------------- > 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
