On Sat, 18 Jun 2016 11:53:37 -0500, Matt Benson wrote:
On Jun 18, 2016 9:28 AM, "Gilles" <gil...@harfang.homelinux.org> wrote:

Hi.


On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible 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)


What are you vetoing?

Or does this veto indeed shows to Ted that Commons refuses to create
new components.



I think it is indicative of the position held by many, myself included, that a set of focused, math-related artifacts do not make sense at the Commons component level, and should be grouped as separate artifacts of
Commons math or a TLP with the same basic structure.

We are getting close to the real problem.

Can we draw the conclusion, at last, that Commons Math does not make
sense in Commons?  [I'd hope so; since you make the point that even a
general functionality like random number generation would not make
sense here, then a monolithic library (with all sorts of math-related
functionalities) makes even less sense here.]

So I think that we could summarize the situation as follows:
 * -1 for new components (Commons refuses)
 * -1 for TLP (Commons refuses)
 * -1 for incubator (until the situation is "clarified")
 * -1 for no change (no committer left)


Gilles

Matt

Not unless the future of the existing CM is clarified and we get
(majority
?) consensus here on the list.


What I hope is clear that any non-bug-fix release of CM 3.x is without
me.


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.


It's not "author" that matters, it's "maintainer".
[It just happens that the two were the same for a lot of the codes in
CM (not a healthy situation indeed).]


Either new people
will stay up to carry on (there are already some new ones)


I discussed that already: counting new contributors and estimating their
future contributions, that still leaves roughly 80% of the code
unsupported.


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.


Again this non-argument?
I answered to that countless times: Major releases are NOT REQUIRED to be
compatible.


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.


How is that different from the scenario of any other major release?
Either I don't understand what you are talking about or it seems that you forbid any release of new code unless everything has been fixed in the
code.

It was never the case and it makes no sense.


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.


I explained my position on this.  And it is not what you state here.

For me, a bug-fix for CM 3.x is OK if the following conditions are both
satisfied:
 1. CM 4.0 is worked on actively and released, and
2. a need is explicitly identified (and those who have this need will
    actively help).

A release of CM 4.0 that is monolithic, targets Java 5 and contains
unsupported code is not OK.


Nobody asked the latter of *you*, just to keep the code untouched
where you have no interest to work with.


I already answered to that point. Code is there; anyone can take from
any point in its history and do whatever he pleases.


Nobody would stop you from working on the rest.


You just did.

As it happens you seem to acknowledge that the fork outside Apache is
the only way to sort out the identified shortcomings of CM.

Is it what you are aiming at by vetoing new components?


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.


How is that different from the POV of Commons?

This time could be better spent in rethinking the codebase in order
to get it right (community-wise) this time.

Legacy users will not upgrade to CM 4.0, whatever it contains.
New users/contributors will not come to maintain a legacy code.

CM is dead.  And we are loosing a lot of time in sterile discussions
about scenarios that DO NOT exist (for CM).


Gilles



- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to