Could we start something in the sandbox? It's not modifying existing code.
On Sat, Jun 18, 2016 at 8:43 AM Jörg Schaible <joerg.schai...@gmx.de> wrote:
> Hi Gilles,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote:
> >> Gilles,
> >>
> >> Thanks for links.
> >>
> >> I just read that (long-winded) thread and I see no consensus that
> >> "Commons
> >> project is not being interested in hosting those components".
> >
> > In line with what I wrote previously, there isn't any consensus on
> > anything
> > within Commons.
> >
> > I'm asking, again, whether I need to initiate a VOTE that would allow
> > me
> > to set up a workspace ("git", etc.) and transfer some code from CM over
> > there.
> > Or can I jut do it? [Some help with doing that is most welcome.]
>
>
> -1 (and this is a veto)
>
> Not unless the future of the existing CM is clarified and we get (majority
> ?) consensus here on the list.
>
>
> >> It may be that incubation is a good thing for Commons Math, but it
> >> doesn't
> >> seem valid to say that incubation is necessary because CM is being
> >> kicked
> >> out of Commons.
> >
> > Never said so.
> >
> > There is a confusion here: *I* say that CM is dead.
> >
> > It was dead already in early February but nobody noticed because *I*
> > (alone) continued to answer the ML, comment on JIRA reports and commit
> > code.
> >
> > Why I was alone doing that became clear when Luc announced his
> > resignation
> > and the fork.
> >
> > The development situation *will* change because the context *has*
> > changed
> > (unsupported code).
> > CM cannot go on as it did before the fork.
>
>
> And this is exactly the question. For me as PMC member of Commons I have to
> look at all components and it is not the first time that the original
> authors of a component vanishes and it won't be the last. Either new people
> will stay up to carry on (there are already some new ones) or the component
> is moved at some point into dormant state, because it gets obsolete (maybe
> because of the fork, future will tell).
>
> However, we care for all Commons components and their usage in the wild.
> Nearly all of our components are buried deep down in some software stacks
> and therefore we always take care to an extreme extent to compatibility of
> new releases. With your proposal to rip CM into parts you leave the current
> users of CM out in the rain. *You* tell them simply to use your new shiny
> components A and B and for the rest they should stay at old CM (that still
> contains on top the old stuff of A and B). Sorry, but this is not a proper
> scenario for Commons.
>
>
> > Everybody (developers, users, Commons PMC) would be better off with a
> > selected set of new (supported) components because this is something we
> > can easily do *now* (RERO, etc.).
>
>
> Again, this is *your* point of view and it is caused by *your* refusal to
> consider a CM release that contains the existing code base, just because
> this includes also code *you* cannot/will not/have no interest to support
> or
> maintain. Nobody asked the latter of *you*, just to keep the code untouched
> where you have no interest to work with. Nobody would stop you from working
> on the rest.
>
>
> > I'm OK to go through the incubator to do that; but I don't see that it
> > is an easier path. Surely it looks longer. And it seems that even the
> > incubator people doubt that it will lead anywhere.
> >
> > Given the uncertain outcome, going through the incubator would be an
> > attempt at rethinking the development of the currently unsupported
> > code. See e.g.
> > https://issues.apache.org/jira/browse/MATH-172
> > [Or is that out of scope for an incubation proposal?]
>
>
> The incubator seems at least to be an option to go forward with CM.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
