What about the Commons Sandox? Would that be a good place to start? Gary
On Thu, May 6, 2021, 09:37 Gilles Sadowski <gillese...@gmail.com> wrote: > 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 > >
