The general pattern that I'm seeing within the NodeJS community is that big
projects are being broken up into smaller projects and those smaller projects
are being broken up yet again, etc. What I find refreshing about that is that
it's pretty simple to find a component / module that I need for which I can
read the example and get up to speed in 5 minutes and if needed read the source
code in less than an hour.
In contrast I'm spending a fairly significant amount of time attempting to
break up CM into smaller, simpler, more easily digestible pieces. Once
something becomes a big library it's very hard to manage it elegantly. Small
projects are easy to manage. For example I'm combining Twitter Bootstrap and
SUIT-CSS into a framework called superfly-css. If you search for it on npmjs
all the modules pop up (A combination of tools and css components):
https://www.npmjs.com/search?q=superfly-css
Each module links back to the parent module for usage documentation, install,
design guidelines, etc. The superfly-css organization landing page is going to
outline all the tool and component modules. Each module can have a gh-pages
branch containing the site for the module if necessary.
I have a very easy time managing this and anyone who uses it gets precisely
what they need. It's like ordering Sushi :) and the process for using the
modules is almost that simple.
This is the best argument I have seen for taking a modular approach:
https://github.com/substack/browserify-handbook#module-philosophy
As an example directly related to CM have a look at the now fairly complete
firefly-math-exceptions module:
https://github.com/firefly-math/firefly-math-exceptions
Anyone on this list can probably read the source in about 10 minutes. It's
very easy to integrate / extend this into any (CM or non CM) math project. So
if we create an organization structure targeting small simple modules I think
we will have a lot more fun with this.
Cheers,
Ole
On 01/25/2016 07:47 AM, 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 :)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
