Le jeu. 6 mai 2021 à 14:48, Emmanuel Bourg <ebo...@apache.org> a écrit : > > Le 2021-05-06 13:06, Gilles Sadowski a écrit : > > > It is not nice to decide for others what they may need. > > It is not nice to suggest I shouldn't voice my opinions.
Your argued opinion is welcome. In the text which you cut, you *explicitly* said that I should go somewhere else (GitHub or whatever). > > > It would have been courteous to acknowledge the answers to > > your argument against having a dedicated component > > I've little appetite for lengthy debate with you again. There is/was no debate (as in: "an exchange of arguments" or "trying to get consensus" or "not forcing me to do what I think is bad"), you state your opinion (as mentioned above) and that's it. > > My rationale, for whether a specific component is needed, has > > always been the same: Define a scope (and stick to it). > > You seem to find this acceptable for any Commons project except > > those which you tagged as "math-related". > > The machine learning scope is too wide, it doesn't belong here. I agree that it is wide, but much less so than "math", yet you never voiced such an opinion against CM (while I did). > > So I'm asking: Will it make any difference if the "machine learning" > > codes are further developed within [Math]? Concretely: > > * Would you vote to release CM v4.0? > > * Would you help (more than if the ML codes were in a > > specific component) to review/merge the PRs? > > I'd would vote favorably for a modularized CM 4.0 release, I really (really, really) can't figure out how you can reconcile that a library (CM) that *contains* a ML subset which you deem too big to be a Commons component, is not too big to be a Commons component! The spin-offs from CM do solve the issue of "too wide scope" that doomed CM. And again: I agree that "machine learning" may be too wide a scope itself; grouping all such algorithms in a single component was already a compromise wrt to having each ML field in its own, especially if we aimed at some common goal (multi-threading) that could lead to shared code (not the math algorithms but, o.a. things, the threads management). > but I still > think that the math related components would be best served in their own > TLP with a dedicated community When this was brought up somewhat seriously, most of the PMC voted against. Then last time (IIRC) the idea was floated, there wasn't the minimum of people required to support a TLP. [FTR, that was the practical reason these codes are here (as is the for all the other Commons components): a place where more people can contribute to otherwise orphaned libraries.] OK, then let's move on; thus I'm asking who in this PMC, is now willing to provide the necessary clearance for an internal fork of the math-related codes for which it is deemed that they are not a good fit for Commons? > free of the Apache Commons rules and > constraints. I'm still to be shown what rules I'd be asking to be free of. Gilles > > Emmanuel Bourg > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
