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