Hi Gary.
On Tue, 25 Oct 2016 14:59:27 -0700, Gary Gregory wrote:
I am against spinning out org.apache.commons.math4.complex out into
yet
another component. The argument that Gilles refuses to
support org.apache.commons.math4.complex because he does not want to
support all of org.apache.commons.math4 in favor of supporting a COPY
of org.apache.commons.math4.complex into org.apache.commons.complex
does
not hold water for me. If I misrepresent, I apologize.
You do misrepresent.
And I've a hard time accepting apologies since you and others make
me repeat, ad nauseum, my technical arguments (of which truthfulness
to the Apache way, as regularly reminded by Dave, is an essential
part).
On Tue, Oct 25, 2016 at 11:00 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
On Tue, 25 Oct 2016 10:32:20 -0700, Gary Gregory wrote:
On Tue, Oct 25, 2016 at 8:46 AM, Jochen Wiedmann <
jochen.wiedm...@gmail.com>
wrote:
Honestly, I really wonder why all this stuff has to fork yet
another
commons component. IMO, CM could just have been changed to emit
multiple jar files with no need for other components. No need for
discussions, no need for new repositories in Git, no need for new
stuff in Jira. Or, to put it different: Less to maintain.
+1
I am against this constant spinning out.
I've argued that the original mistake was to let CM extend beyond
the stat toolbox it was when the component was created.
Please refer to the ML archive.
That's way in the past and we have math3 and math4 now.
Sure, way in the past was the mistake, which the CM team always
refused to tackle.
As long as they were regular contributors, their opinion was
essential to the continuation of CM.
It is a distinctive feature of this PMC, that people who do not
did any of the work, neither before the fork, nor after, think
they are right to block, for months now, the continuation of an
alternative project.
There cannot be a consensus of you forcing us do what we
consider is heading in the wrong direction, on the basis that
still others (who have now left the project) took some decisions
way in the past.
The fix is to separate what was never actually a coherent whole
(from the contents, programming style, and management POVs).
That's not a "fix". That's a complete re-architecting,
Yes.
I proposed to do it inside CM.
It was refused; and there is a _valid_ argument that it was not
necessary to perform the re-design within the CM component: leave
open the possibility that an alternative team wants to take it
over from there.
It just happens that for now there is nobody in that team.
Those in the PMC who favor that alternative did not do anything
to make it more than a pipe-dream.
hence perhaps the
"H" project.
Certainly not: that project continues on the same road which I
pointedly want us to leave.
[Which the notable exceptions that they made some changes which
they refused to do when in "Commons"!]
I've argued why we cannot do what they do (see the archives).
If you are against something, you have to provide a technical
argument. There can be none (see previous paragraph).
What you provide is not a technical argument, it's an opinion, IMO
;-)
How so?
Moving code around and putting bits in different buckets is not a
technical
argument IMO. That's just managing deliverables, which is worth
talking
about.
It's partly that, indeed, but hardly only that.
For the n-th time: what is at stake is the "liveness" of a project
that had a lot of good code within it, but that never succeeded
in attracting a diverse community because, because... well see the
archives!
Gilles
Gary
This discussion could have been the business of a new TLP (as
promoted by James Carman).
This has been REFUSED.
People are willing to actively create, maintain and use an
eco-system of components on which they are more expert than
anyone else here.
And people who never read a single line from the CM codebase
would just be "against" it?
Gilles
Gary
On Sat, Oct 22, 2016 at 1:42 PM, Eric Barnhill
<ericbarnh...@gmail.com>
wrote:
> As the recent contribution shows the commons-math complex
library
remains
> quite useful to many applications.
>
> Following in the footsteps of commons-rng, commons-complex seems
like a
> good next component of math to spin out and actively maintain. I
am
willing
> to oversee and maintain the project.
>
> It may be that as I get into it, complex will have dependencies
that
more
> properly belong in a core library. I propose to just get started
on the
> library and sort these issues as they come up.
>
> I would take the following positions as regards this library:
>
> - Add syntactic sugar so that typical C++ calls are compatible:
yes
> - Keep completely backwards compatible: yes
> - Follow the C++ architecture including an Imaginary data type
with its
own
> behavior: no
> - Like C++, incorporate complex typing other than double: no
>
> -Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
