On Sun, 10 Sep 2017 12:35:17 -0400, Raymond DeCampo wrote:
I know I haven't been around lately, but I this exchange caught my
eye.
I was trying to figure out a way to balance the issues, first, that
there
is resistance to creating a large number of projects spun out from CM
Depending on what is being counted (released, approved by
contributors, approved by PMC), "large" would qualify a
quantity that varies between 2 and 5.
[The supposed amount of added work has been long dwarfed
by endless arguing that amounts to discouraging any further
work on CM code.]
So the "resistance" argues on a baseless fear.
and
second, that there is a practical limit to how large a project can be
maintained with the current resources.
That is a fact, proved by the last two years of (in)activity
on CM.
What I came up with is as follows: suppose we take CM and split it
up into
a number of modules. Then within the project we treat each module
independently for the purposes of maintenance, release etc. So that
if the
geometry module is ready to cut a new release it may do so without
being
held up by issues in the other modules.
So, how to accomplish this and still have CM appear to be and behave
like
one project? Each module would have it's own development branch. In
the
master branch would be a copy of the last released version of each
module.
Development happens in the development branch. When a module is
ready to
release, it merges into the master branch, bumps the version and
releases
the whole thing (i.e. all of CM).
So, e.g. say CM 4.3.5 has versions 4.1.7 of the linear algebra module
and
4.2.8 of the geometry module. The geometry module is ready to make a
new
release, so it merges into master and bumps CM to 4.3.6 and geometry
to
4.2.9. The linear algebra module stays at 4.1.7. So CM 4.3.6 is the
same
as 4.3.5 except for the geometry module, which is now at 4.2.9.
Please (re)read that thread (from 10 months ago):
http://markmail.org/message/2674qemtl5vvrnum
Is your proposal different?
While working this out I took a stab at splitting CM into modules. I
ran
into issues with the stats & distribution packages as many of the
tests for
other classes depend on them. So there's some work there to detangle
some
of the packages. But I was able to split out geometry, transform,
optimizers, filter, diffeq and machine learning without a lot of
trouble.
See https://github.com/RayDeCampo/commons-math/tree/modules if you
are
interested.
This pretty much agrees with my observations (and analyses
thereof), presented here several times, last installment of
which was:
http://markmail.org/message/rzvh3esin3neffqs
Regards,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
