On Mon, 25 Jan 2016 07:15:20 -0700, Phil Steitz wrote:
On 1/25/16 7:01 AM, Gilles wrote:
On Mon, 25 Jan 2016 06:47:40 -0700, Phil Steitz wrote:
On 1/25/16 12:40 AM, Ole Ersoy wrote:
Umbrella-ish is good. Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella. Some of the other Apache projects that do math may be
interested in moving that piece under the Apache Math umbrella.
The ASF does not look favorably on "umbrella" projects. This is
because in these projects, the individual volunteers making up the
PMC inevitably lose sight of the full project. The governance
model
that we have at Apache has no layers in it beneath the PMC. That
means PMCs need to be focused. "All things X" PMCs don't work.
The
canonical example of that was Jakarta, which started as "all things
Java" and was eventually split up. We should definitely not try to
be "all things math" at the ASF. A better focus would be a nice
set
math components in Java that other math-related projects inside and
outside the ASF can use. Kind of like, um, Commons Math as its own
TLP :)
The problem is that Commons Math is "all things math-related that
the
PMC agreed to put in". It is an umbrella in the sense you
describe here
(even if obviously cannot preclude other project to implement math
routines).
We have seen that a CM-like project has advantages and drawbacks,
for
developers and users.
It makes sense to dig further into Ole's proposal towards
modularization
because, if it is as you say above, then different modules may
have to
become different projects!
If they don't have to, then I don't understand your argument.
Or it is a fight on the use of the word "umbrella"?
The ASF principle is simple: the PMC has to provide active
oversight of the project. That means that you can't have a single
project effectively split into several smaller ones with individual
PMC members providing oversight to parts, but not the whole. When
that starts to happen, you need to break the project apart. Just
distributing separate jars does not force that to happen.
It is a sound principle.
But is it always applicable in practice?
I mean, for CM precisely, it is not true that everyone oversees
to whole code base. The following situations happened:
* single individuals coded (or refactored) almost everything in a
package and nobody else participated in the design, or reviewed
the resulting code
* some packages are too venerable to be touched by newbies
* code contained crippling bugs, that have gone unnoticed for a long
time
* some people want to refactor part or the whole of a package but
others block it on non-technical ground
Hence, without bypassing the good principle, it could be made clear
that some people are more interested or knowledgeable in some area
of the library, and thus the primary (informal) responsible for its
design, not precluding the binding advice of other PMC members.
There should be consensus... (?) on the principle of how to adapt the
principle to reality.
Then modules with better defined scopes could be developed according
to possibly different policies (see "PMC volunteering" thread).
Gilles
Phil
Gilles
Phil
Personally I like to see each in a separate repository dedicated
to the subject, along with the corresponding documentation, etc
So:
apache-math (Central repository describing the project as a whole
with the documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.
And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..
Cheers,
Ole
On 01/24/2016 04:41 PM, Phil Steitz wrote:
On Jan 24, 2016, at 3:17 PM, Gilles
<gil...@harfang.homelinux.org> wrote:
Just plain and simple "Apache Math" maybe?
Or is it taken already?
It's not taken; but I thought it was too broad-sounding and in
fact umbrella-ish. There are other ASF projects that do
math-relates things. I think adding "components" makes it look
more like a library of base components that other math-related
projects can use.
Phil
Gilles
On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.
This is slightly jumping the gun, as we do have the
opportunity in
forming the new TLP to revisit the initial goals of [math];
but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common
math
programming problems. We have grown to the point where we will
almost certainly break the distribution up into separate
"components." No umbrella, but likely multiple release
artifacts.
Similar in some ways to what happened with [http], which is
why I
suggested the same approach to naming.
Regarding picking a mathematician for the name, I don't much
like
that idea as whoever you choose, you end up loading some math
area
and / or cultural bias into the name.
Phil
Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton?
Apache Euler?
Apache Euclid?
On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
<phil.ste...@gmail.com> wrote:
We need to agree on a name. My own preference is for a
boring,
descriptive name, but I am manifestly not a marketing guy, so
won't
be offended if others want to be more creative.
My suggestion is
MathComponents
Hearkens back to HttpComponents, which has worked pretty
well.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
