Le 17/01/2016 18:45, Phil Steitz a écrit : > 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
Done. Luc > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
