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? 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