[All][Math] New component: "Commons Geometry"?

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Emmanuel Bourg-3
Le 4/09/2017 à 15:30, Gilles a écrit :

> I see it as a fundamental one: Why should codes unrelated
> by scope be artificially tied together by management rules
> (such as design, supported language version, release schedule,
> etc.)?[1]

Because they share the same general scope of being math related. The
design and the supported language version can be different for each module.


> Why do you "prefer" multi-module, independently of the subject
> matters being talked about?

I already explained twice in this thread.


> Please comment on my suggestion to create a single maven project
> for the whole of "Commons".  I'd agree that this suggestion is
> ridiculous; yet some of you do the same proposal for "everything
> math-related".

If you want to use an absurd proposal to prove your point let me try
that game too: Please comment on my suggestion to create multiple
components out of every Java package defined in the Commons components.


> If you had been contributing to the math codes (plural), you
> perhaps would have understood that it creates more management
> problems than it solves.[4]

Please use foot references for external links only, your messages are
unreadable if we have to go back and forth to understand them.


> Again, I have to stress on what happened that led me to propose
> a new "Commons RNG": obvious improvements to the CM code base
> were outrightly rejected based on demonstrably false statements;
> i.e. the objections were not technical but for the convenience
> of one user.

I still think that splitting RNG into its own component was a good move.
I'm less happy with Numbers, I'd have preferred a module from a
renovated "CM5" project started from scratch as I'm suggesting now for
Geometry.


> Do you think that I enjoy contradicting you on these matters?

I'm starting to think that you enjoy rhetoric, probably more than
seeking compromise unfortunately.


> Do they want to implement another plan?  What plan?

Here is my counter-proposal:

1. Refactor Commons Math as a multi-module project, bump to version 5
2. Create two modules: geometry and legacy
3. Release Commons Math 5, without the legacy module
4. Spin-off new modules from the legacy module when needed

And I'm willing to help at least for the steps 1 and 2.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Raymond DeCampo
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 and
second, that there is a practical limit to how large a project can be
maintained with the current resources.

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.

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.


On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 4/09/2017 à 15:30, Gilles a écrit :
>
> > I see it as a fundamental one: Why should codes unrelated
> > by scope be artificially tied together by management rules
> > (such as design, supported language version, release schedule,
> > etc.)?[1]
>
> Because they share the same general scope of being math related. The
> design and the supported language version can be different for each module.
>
>
> > Why do you "prefer" multi-module, independently of the subject
> > matters being talked about?
>
> I already explained twice in this thread.
>
>
> > Please comment on my suggestion to create a single maven project
> > for the whole of "Commons".  I'd agree that this suggestion is
> > ridiculous; yet some of you do the same proposal for "everything
> > math-related".
>
> If you want to use an absurd proposal to prove your point let me try
> that game too: Please comment on my suggestion to create multiple
> components out of every Java package defined in the Commons components.
>
>
> > If you had been contributing to the math codes (plural), you
> > perhaps would have understood that it creates more management
> > problems than it solves.[4]
>
> Please use foot references for external links only, your messages are
> unreadable if we have to go back and forth to understand them.
>
>
> > Again, I have to stress on what happened that led me to propose
> > a new "Commons RNG": obvious improvements to the CM code base
> > were outrightly rejected based on demonstrably false statements;
> > i.e. the objections were not technical but for the convenience
> > of one user.
>
> I still think that splitting RNG into its own component was a good move.
> I'm less happy with Numbers, I'd have preferred a module from a
> renovated "CM5" project started from scratch as I'm suggesting now for
> Geometry.
>
>
> > Do you think that I enjoy contradicting you on these matters?
>
> I'm starting to think that you enjoy rhetoric, probably more than
> seeking compromise unfortunately.
>
>
> > Do they want to implement another plan?  What plan?
>
> Here is my counter-proposal:
>
> 1. Refactor Commons Math as a multi-module project, bump to version 5
> 2. Create two modules: geometry and legacy
> 3. Release Commons Math 5, without the legacy module
> 4. Spin-off new modules from the legacy module when needed
>
> And I'm willing to help at least for the steps 1 and 2.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Matt Benson-3
I'm another Commons developer who:
 * Hasn't been "present" lately
 * Has no special mathematical background
 * Desires consensus
 * Repeatedly reads these exchanges in a state of vacillation between
sympathy for Gilles's situation and suspicion that his communication style
is too abrasive. Ultimately, I get that you're frustrated.

I too have felt all along that Maven modules would be an acceptable
approach wrt CM, but my view (in which I am seemingly not alone) of that
set of code as "alike" simply because it relates to mathematics is, as I
imply above, very likely rooted in ignorance. At the same time, the field
of software development is only hoped to become more accessible by those
with decreasing amounts of formal education, so perhaps it is fair that the
line be drawn in the interest of the mathematical outsider.

Even I have a reasonable understanding of basic geometry and can appreciate
that there may be more situations in which its use would be "common." On
the other hand, it still clearly feels like I would expect to find that
among "math" code. As Ray has pointed out, there is no *technical* reason a
Maven project's submodules must have synchronized release schedule or
version numbers. It would seem to me that his approach, perhaps accounting
for the notion of the "legacy" submodule, while undeniably increasing
complexity of management to some extent, still seems the most likely way
forward to give all parties *enough* satisfaction. We are developers: we
should be able to create tooling, e.g. in Jenkins or elsewhere, that could
help manage the coordination of version numbers between parent and children.

In any case, Gilles's statement that geometry represents the outer edge of
his vision for CM expansion means that this discussion needed to take place
soon anyway; the only remaining decisions should IMO be 1) whether geometry
belongs with CM5, and 2) whether numbers should be reabsorbed into such a
CM5 structure.

Matt

On Sep 10, 2017 11:35, "Raymond DeCampo" <[hidden email]> 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 and
second, that there is a practical limit to how large a project can be
maintained with the current resources.

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.

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.


On Tue, Sep 5, 2017 at 8:33 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 4/09/2017 à 15:30, Gilles a écrit :
>
> > I see it as a fundamental one: Why should codes unrelated
> > by scope be artificially tied together by management rules
> > (such as design, supported language version, release schedule,
> > etc.)?[1]
>
> Because they share the same general scope of being math related. The
> design and the supported language version can be different for each
module.

>
>
> > Why do you "prefer" multi-module, independently of the subject
> > matters being talked about?
>
> I already explained twice in this thread.
>
>
> > Please comment on my suggestion to create a single maven project
> > for the whole of "Commons".  I'd agree that this suggestion is
> > ridiculous; yet some of you do the same proposal for "everything
> > math-related".
>
> If you want to use an absurd proposal to prove your point let me try
> that game too: Please comment on my suggestion to create multiple
> components out of every Java package defined in the Commons components.
>
>
> > If you had been contributing to the math codes (plural), you
> > perhaps would have understood that it creates more management
> > problems than it solves.[4]
>
> Please use foot references for external links only, your messages are
> unreadable if we have to go back and forth to understand them.
>
>
> > Again, I have to stress on what happened that led me to propose
> > a new "Commons RNG": obvious improvements to the CM code base
> > were outrightly rejected based on demonstrably false statements;
> > i.e. the objections were not technical but for the convenience
> > of one user.
>
> I still think that splitting RNG into its own component was a good move.
> I'm less happy with Numbers, I'd have preferred a module from a
> renovated "CM5" project started from scratch as I'm suggesting now for
> Geometry.
>
>
> > Do you think that I enjoy contradicting you on these matters?
>
> I'm starting to think that you enjoy rhetoric, probably more than
> seeking compromise unfortunately.
>
>
> > Do they want to implement another plan?  What plan?
>
> Here is my counter-proposal:
>
> 1. Refactor Commons Math as a multi-module project, bump to version 5
> 2. Create two modules: geometry and legacy
> 3. Release Commons Math 5, without the legacy module
> 4. Spin-off new modules from the legacy module when needed
>
> And I'm willing to help at least for the steps 1 and 2.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
On Tue, 5 Sep 2017 14:33:55 +0200, Emmanuel Bourg wrote:
> Le 4/09/2017 à 15:30, Gilles a écrit :
>
>> I see it as a fundamental one: Why should codes unrelated
>> by scope be artificially tied together by management rules
>> (such as design, supported language version, release schedule,
>> etc.)?[1]
>
> Because they share the same general scope of being math related.

This is what CM was about, and it did not work out well.
Been there, done that.

> The
> design and the supported language version can be different for each
> module.

Which project would start on the premises of a non-uniform
design among its modules?

It makes sense if the projects are different and can be
supported by different teams (even if there can be overlaps
of course).

>> Why do you "prefer" multi-module, independently of the subject
>> matters being talked about?
>
> I already explained twice in this thread.

You did not because you left out the _why_ you don't agree
that "Mathematics" is too broad a scope for a programming
project.
At least a project which we could handle here at "Commons"
(being a home for small, focused, components).

CM was proven not to be a viable component for "Commons" in
several ways: some decided to leave "Commons", some proposed
to adapt our expectations to match the "Commons" eco-system
(code-wise and community-wise, as I've explained in more than
one way).

A few others still insist that what led to much disappointment
should be pursued.
Same cause, same consequences.

>> Please comment on my suggestion to create a single maven project
>> for the whole of "Commons".  I'd agree that this suggestion is
>> ridiculous; yet some of you do the same proposal for "everything
>> math-related".
>
> If you want to use an absurd proposal to prove your point let me try
> that game too: Please comment on my suggestion to create multiple
> components out of every Java package defined in the Commons
> components.

You, not me, are advocating for an absurd proposal whose
logical consequence would allow including the whole of
mathematics in a single maven project.

I start from the subject matter in order to define scope.
This has nothing to do with what you are presenting here
(which is indeed absurd too).

>> If you had been contributing to the math codes (plural), you
>> perhaps would have understood that it creates more management
>> problems than it solves.[4]
>
> Please use foot references for external links only, your messages are
> unreadable if we have to go back and forth to understand them.
>
>
>> Again, I have to stress on what happened that led me to propose
>> a new "Commons RNG": obvious improvements to the CM code base
>> were outrightly rejected based on demonstrably false statements;
>> i.e. the objections were not technical but for the convenience
>> of one user.
>
> I still think that splitting RNG into its own component was a good
> move.
> I'm less happy with Numbers, I'd have preferred a module from a
> renovated "CM5" project started from scratch as I'm suggesting now
> for
> Geometry.

Good for "RNG", bad for "Numbers"...  Where is the logic?

Even so, how long did it take the PMC to see that "Commons
RNG" was a good move?

If "Commons RNG" was a good move, you could have the minimal
trust that maybe, just maybe, I might be right with a quite
limited set of similar suggestions resulted from an identical
reasoning.

>> Do you think that I enjoy contradicting you on these matters?
>
> I'm starting to think that you enjoy rhetoric,

I'm not.  But you seem on to try and blur my true position, with
undertones that I'd be more "talking" than "doing".

All evidences are there: the ML archives, the bugs, the fork,
the new components (released and in-progress).
But you look only at a couple of "mechanical" advantages of
having N-1 components rather than N.

> probably more than
> seeking compromise unfortunately.

And this accusation, yet again. :-/
Surely you do not have a clear memory of more than 10 years of
day-to-day CM development; I did compromise on very wrong (IMO)
decisions.
And I have taken more than my share implementing some of those
wrong decisions, trusting that the others would do their part.
Did you notice the result?

Errare humanum est, perseverare diabolicum.

>> Do they want to implement another plan?  What plan?
>
> Here is my counter-proposal:
>
> 1. Refactor Commons Math as a multi-module project, bump to version 5
> 2. Create two modules: geometry and legacy
> 3. Release Commons Math 5, without the legacy module
> 4. Spin-off new modules from the legacy module when needed
>
> And I'm willing to help at least for the steps 1 and 2.

I'm not sure I understand your intended level of implication.
[Changing the directory structure of the repository is the
trivial part of the process.  Stopping there is like shoving
dust under carpet to pretend that the floor is clean.]

I propose that "Commons Numbers" and "Commons Geometry" be
components (with their own set of modules); and, from the
rest of CM code, we'd have
1. easy "module" candidates like:
      o.a.c.m.distribution (unidimensional)
      o.a.c.m.ml
      o.a.c.m.genetic
2. less easy ones (cyclic dependencies or dependencies on
    "legacy", non-trivial issues, lack of support), such as
    parts of
      o.a.c.m.analysis
      o.a.c.m.analysis.integration
      o.a.c.m.distribution (multidimensional)
      o.a.c.m.fitting
      o.a.c.m.optim
      o.a.c.m.ode
      o.a.c.m.filter
3. "legacy" (refactoring issues, lack of support) for
      o.a.c.m.linear
      o.a.c.m.stat

Some of the modules should in principle be separate components
too, but this depends on the developers who had volunteered
to populate them...

Let's hear from people who actually intend to work.  What
are they willing to do for the result which they would like
to see?

Personally, as I've said recently, I'm not willing to be the
one supposed to handle tasks "3." and "4." for the years to
come. Been there, done that.


Gilles

>
> Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Raymond DeCampo
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Raymond DeCampo
On Mon, Sep 11, 2017 at 1:20 PM, Gilles <[hidden email]>
wrote:

> 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
>>
> 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?


One difference is that I proposed an overarching CM version, in the same
way that, e.g. JEE X is comprised of many versions of smaller standards.
However much of the discussion in that thread still applies.


>
>
> 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



Yes, I used your posts as a roadmap when splitting it up.
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

jochen-2
In reply to this post by Gilles Sadowski
On Sat, Sep 2, 2017 at 12:50 AM, Gilles <[hidden email]> wrote:

> Because of "Commons" rules, it is not "equivalent": There was
> a long thread concluding that all modules must be released
> _together_, and with the same top-level package name and version
> number.
> It is very "maintainer(s)-unfriendly" because of the quite
> different subject matters that coexist in CM.

I wouldn't count that rule "*all* modules must be released" as a mantra:

a) In case of an emergency release (fixing a CVE, for example), I'd
clearly consider pushing out the module as more important than waiting
for a full release. (Of course, one must be careful to maintain
compatibility when pushing out just a module, but that goes without
saying.)
b) I'd like to hear others experiences on that topic (maybe VFS).
Anyways, my personal experiences with Rat are clear: Releasing *all*
together is causing nothing but pain, and tends to defer releases
indefinitely. OTOH, releasing a submodule can be done at all times,
and without overly much preparation.

In conclusion, I'd definitely support the release of a single
submodule, if the need would arise.

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Jörg Schaible
Hi Jochen,

Jochen Wiedmann wrote:

> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <[hidden email]>
> wrote:
>
>> Because of "Commons" rules, it is not "equivalent": There was
>> a long thread concluding that all modules must be released
>> _together_, and with the same top-level package name and version
>> number.
>> It is very "maintainer(s)-unfriendly" because of the quite
>> different subject matters that coexist in CM.
>
> I wouldn't count that rule "*all* modules must be released" as a mantra:
>
> a) In case of an emergency release (fixing a CVE, for example), I'd
> clearly consider pushing out the module as more important than waiting
> for a full release. (Of course, one must be careful to maintain
> compatibility when pushing out just a module, but that goes without
> saying.)
> b) I'd like to hear others experiences on that topic (maybe VFS).
> Anyways, my personal experiences with Rat are clear: Releasing *all*
> together is causing nothing but pain, and tends to defer releases
> indefinitely. OTOH, releasing a submodule can be done at all times,
> and without overly much preparation.
>
> In conclusion, I'd definitely support the release of a single
> submodule, if the need would arise.

Just that our tooling does not support this:
1/ No proper support for release of a GIT subtree
2/ No proper support for such a site generation
3/ No proper support using the release plugin
4/ Parents of such a component will have their own release cycle
...

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by jochen-2
On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:

> On Sat, Sep 2, 2017 at 12:50 AM, Gilles
> <[hidden email]> wrote:
>
>> Because of "Commons" rules, it is not "equivalent": There was
>> a long thread concluding that all modules must be released
>> _together_, and with the same top-level package name and version
>> number.
>> It is very "maintainer(s)-unfriendly" because of the quite
>> different subject matters that coexist in CM.
>
> I wouldn't count that rule "*all* modules must be released" as a
> mantra:

I found the idea attractive, but Stian (link to older discussion
in a previous post) advised that maven would not easily "support"
it.

Has that changed since the discussion took place (10 months ago)?

> a) In case of an emergency release (fixing a CVE, for example), I'd
> clearly consider pushing out the module as more important than
> waiting
> for a full release. (Of course, one must be careful to maintain
> compatibility when pushing out just a module, but that goes without
> saying.)
> b) I'd like to hear others experiences on that topic (maybe VFS).
> Anyways, my personal experiences with Rat are clear: Releasing *all*
> together is causing nothing but pain, and tends to defer releases
> indefinitely. OTOH, releasing a submodule can be done at all times,
> and without overly much preparation.
>
> In conclusion, I'd definitely support the release of a single
> submodule, if the need would arise.

How can one reconcile what you say here with what was said in
that old thread?

Would the PMC accept that a component contains independent modules
(where "independent" means that each module can have its own version
number, irrespective of the component's version)?

Arguably (cf. thread referred to above), a "Commons" component
should be simple enough that multiple versions are not necessary.
[Chorus:] This is not the case with "Commons Math", hence separate
components for independent contents (such as "Geometry", "RNG",
"Numbers" and "SigProc") is the simplest solution.

Gilles

> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Amey Jadiye
Pardon me for pulling this thread up again, I havent read anything about
"Commons Geometry" since long (or may be I missed any other disscussion? ).
is someone working on this ? what is the final decision ? I'm having good
amount of time to spend on this now, appreciate If someone direct me to
correct disscussion thread I think I can help here.
It took me half hour to read all old mails but dont see final verdict,
though I was in favour with Maven modules but after reading all again  I
think Gilles approch is more practicle here and If no one is working I can
submit something to review.

Regards,
Amey

On Wed, Sep 13, 2017 at 4:44 AM, Gilles <[hidden email]>
wrote:

> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>
>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <[hidden email]>
>> wrote:
>>
>> Because of "Commons" rules, it is not "equivalent": There was
>>> a long thread concluding that all modules must be released
>>> _together_, and with the same top-level package name and version
>>> number.
>>> It is very "maintainer(s)-unfriendly" because of the quite
>>> different subject matters that coexist in CM.
>>>
>>
>> I wouldn't count that rule "*all* modules must be released" as a mantra:
>>
>
> I found the idea attractive, but Stian (link to older discussion
> in a previous post) advised that maven would not easily "support"
> it.
>
> Has that changed since the discussion took place (10 months ago)?
>
> a) In case of an emergency release (fixing a CVE, for example), I'd
>> clearly consider pushing out the module as more important than waiting
>> for a full release. (Of course, one must be careful to maintain
>> compatibility when pushing out just a module, but that goes without
>> saying.)
>> b) I'd like to hear others experiences on that topic (maybe VFS).
>> Anyways, my personal experiences with Rat are clear: Releasing *all*
>> together is causing nothing but pain, and tends to defer releases
>> indefinitely. OTOH, releasing a submodule can be done at all times,
>> and without overly much preparation.
>>
>> In conclusion, I'd definitely support the release of a single
>> submodule, if the need would arise.
>>
>
> How can one reconcile what you say here with what was said in
> that old thread?
>
> Would the PMC accept that a component contains independent modules
> (where "independent" means that each module can have its own version
> number, irrespective of the component's version)?
>
> Arguably (cf. thread referred to above), a "Commons" component
> should be simple enough that multiple versions are not necessary.
> [Chorus:] This is not the case with "Commons Math", hence separate
> components for independent contents (such as "Geometry", "RNG",
> "Numbers" and "SigProc") is the simplest solution.
>
> Gilles
>
> Jochen
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
Hello Amey.

On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
> Pardon me for pulling this thread up again, I havent read anything
> about
> "Commons Geometry" since long

Thanks for your renewed interest.

> (or may be I missed any other disscussion? ).

Probably not.

> is someone working on this ?

It would be a surprise.

> what is the final decision ?

There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).

> I'm having good
> amount of time to spend on this now, appreciate If someone direct me
> to
> correct disscussion thread

IIRC, the one below is where we left off...

> I think I can help here.

Thanks for the offer!

> It took me half hour to read all old mails but dont see final
> verdict,
> though I was in favour with Maven modules but after reading all again
> I
> think Gilles approch is more practicle here and If no one is working
> I can
> submit something to review.

IMHO, the priority would be to review the status of "Numbers"
(i.e. what is preventing a first release?).

Best regards,
Gilles


> Regards,
> Amey
>
> On Wed, Sep 13, 2017 at 4:44 AM, Gilles
> <[hidden email]>
> wrote:
>
>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>>
>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>> Because of "Commons" rules, it is not "equivalent": There was
>>>> a long thread concluding that all modules must be released
>>>> _together_, and with the same top-level package name and version
>>>> number.
>>>> It is very "maintainer(s)-unfriendly" because of the quite
>>>> different subject matters that coexist in CM.
>>>>
>>>
>>> I wouldn't count that rule "*all* modules must be released" as a
>>> mantra:
>>>
>>
>> I found the idea attractive, but Stian (link to older discussion
>> in a previous post) advised that maven would not easily "support"
>> it.
>>
>> Has that changed since the discussion took place (10 months ago)?
>>
>> a) In case of an emergency release (fixing a CVE, for example), I'd
>>> clearly consider pushing out the module as more important than
>>> waiting
>>> for a full release. (Of course, one must be careful to maintain
>>> compatibility when pushing out just a module, but that goes without
>>> saying.)
>>> b) I'd like to hear others experiences on that topic (maybe VFS).
>>> Anyways, my personal experiences with Rat are clear: Releasing
>>> *all*
>>> together is causing nothing but pain, and tends to defer releases
>>> indefinitely. OTOH, releasing a submodule can be done at all times,
>>> and without overly much preparation.
>>>
>>> In conclusion, I'd definitely support the release of a single
>>> submodule, if the need would arise.
>>>
>>
>> How can one reconcile what you say here with what was said in
>> that old thread?
>>
>> Would the PMC accept that a component contains independent modules
>> (where "independent" means that each module can have its own version
>> number, irrespective of the component's version)?
>>
>> Arguably (cf. thread referred to above), a "Commons" component
>> should be simple enough that multiple versions are not necessary.
>> [Chorus:] This is not the case with "Commons Math", hence separate
>> components for independent contents (such as "Geometry", "RNG",
>> "Numbers" and "SigProc") is the simplest solution.
>>
>> Gilles
>>
>> Jochen
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Amey Jadiye
On Fri, Dec 1, 2017 at 6:56 PM, Gilles <[hidden email]> wrote:

> Hello Amey.


Hi Gilles,

>
>
> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>
>> Pardon me for pulling this thread up again, I havent read anything about
>> "Commons Geometry" since long
>>
>
> Thanks for your renewed interest.
>
> (or may be I missed any other disscussion? ).
>>
>
> Probably not.
>
> is someone working on this ?
>>
>
> It would be a surprise.
>
> what is the final decision ?
>>
>
> There hasn't been any progress towards a decision.
>

I'm not sure if "Lazy Consensus" works in these matters ? better take help
of it, its fast and easy.


> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).
>
> I'm having good
>> amount of time to spend on this now, appreciate If someone direct me to
>> correct disscussion thread
>>
>
> IIRC, the one below is where we left off...
>
> I think I can help here.
>>
>
> Thanks for the offer!
>
> It took me half hour to read all old mails but dont see final verdict,
>> though I was in favour with Maven modules but after reading all again I
>> think Gilles approch is more practicle here and If no one is working I can
>> submit something to review.
>>
>
> IMHO, the priority would be to review the status of "Numbers"
> (i.e. what is preventing a first release?).
>

Ok, If commons number is priority let me check that first, I will chime in
here after that release.
last numbers release I see on 22/4/17, and total open jiras are 18, what
are min expectation here ?
I will open another thread If want advise., let this thread alive for
o.a.c.geometry.

Regards,
Amey


> Best regards,
> Gilles
>
>
>
> Regards,
>> Amey
>>
>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles <[hidden email]>
>> wrote:
>>
>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>>>
>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>> Because of "Commons" rules, it is not "equivalent": There was
>>>>
>>>>> a long thread concluding that all modules must be released
>>>>> _together_, and with the same top-level package name and version
>>>>> number.
>>>>> It is very "maintainer(s)-unfriendly" because of the quite
>>>>> different subject matters that coexist in CM.
>>>>>
>>>>>
>>>> I wouldn't count that rule "*all* modules must be released" as a mantra:
>>>>
>>>>
>>> I found the idea attractive, but Stian (link to older discussion
>>> in a previous post) advised that maven would not easily "support"
>>> it.
>>>
>>> Has that changed since the discussion took place (10 months ago)?
>>>
>>> a) In case of an emergency release (fixing a CVE, for example), I'd
>>>
>>>> clearly consider pushing out the module as more important than waiting
>>>> for a full release. (Of course, one must be careful to maintain
>>>> compatibility when pushing out just a module, but that goes without
>>>> saying.)
>>>> b) I'd like to hear others experiences on that topic (maybe VFS).
>>>> Anyways, my personal experiences with Rat are clear: Releasing *all*
>>>> together is causing nothing but pain, and tends to defer releases
>>>> indefinitely. OTOH, releasing a submodule can be done at all times,
>>>> and without overly much preparation.
>>>>
>>>> In conclusion, I'd definitely support the release of a single
>>>> submodule, if the need would arise.
>>>>
>>>>
>>> How can one reconcile what you say here with what was said in
>>> that old thread?
>>>
>>> Would the PMC accept that a component contains independent modules
>>> (where "independent" means that each module can have its own version
>>> number, irrespective of the component's version)?
>>>
>>> Arguably (cf. thread referred to above), a "Commons" component
>>> should be simple enough that multiple versions are not necessary.
>>> [Chorus:] This is not the case with "Commons Math", hence separate
>>> components for independent contents (such as "Geometry", "RNG",
>>> "Numbers" and "SigProc") is the simplest solution.
>>>
>>> Gilles
>>>
>>> Jochen
>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--

---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Amey Jadiye
On Fri, Dec 1, 2017 at 7:23 PM, Amey Jadiye <[hidden email]> wrote:

>
>
> On Fri, Dec 1, 2017 at 6:56 PM, Gilles <[hidden email]>
> wrote:
>
>> Hello Amey.
>
>
> Hi Gilles,
>
>>
>>
>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>
>>> Pardon me for pulling this thread up again, I havent read anything about
>>> "Commons Geometry" since long
>>>
>>
>> Thanks for your renewed interest.
>>
>> (or may be I missed any other disscussion? ).
>>>
>>
>> Probably not.
>>
>> is someone working on this ?
>>>
>>
>> It would be a surprise.
>>
>> what is the final decision ?
>>>
>>
>> There hasn't been any progress towards a decision.
>>
>
> I'm not sure if "Lazy Consensus" works in these matters ? better take help
> of it, its fast and easy.
>
>
>> There isn't even a consensus on one of the central tenets of
>> Apache ("Those who do the work..."): how sad/strange (?).
>>
>> I'm having good
>>> amount of time to spend on this now, appreciate If someone direct me to
>>> correct disscussion thread
>>>
>>
>> IIRC, the one below is where we left off...
>>
>> I think I can help here.
>>>
>>
>> Thanks for the offer!
>>
>> It took me half hour to read all old mails but dont see final verdict,
>>> though I was in favour with Maven modules but after reading all again I
>>> think Gilles approch is more practicle here and If no one is working I
>>> can
>>> submit something to review.
>>>
>>
>> IMHO, the priority would be to review the status of "Numbers"
>> (i.e. what is preventing a first release?).
>>
>
> Ok, If commons number is priority let me check that first, I will chime in
> here after that release.
> last numbers release I see on 22/4/17,
>

apologies, that date belongs to site publish and SNAPSHOT, not the alpha
release.

and total open jiras are 18, what are min expectation here ?

> I will open another thread If want advise., let this thread alive for
> o.a.c.geometry.
>
> Regards,
> Amey
>
>
>> Best regards,
>> Gilles
>>
>>
>>
>> Regards,
>>> Amey
>>>
>>> On Wed, Sep 13, 2017 at 4:44 AM, Gilles <[hidden email]>
>>> wrote:
>>>
>>> On Tue, 12 Sep 2017 13:07:24 +0200, Jochen Wiedmann wrote:
>>>>
>>>> On Sat, Sep 2, 2017 at 12:50 AM, Gilles <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> Because of "Commons" rules, it is not "equivalent": There was
>>>>>
>>>>>> a long thread concluding that all modules must be released
>>>>>> _together_, and with the same top-level package name and version
>>>>>> number.
>>>>>> It is very "maintainer(s)-unfriendly" because of the quite
>>>>>> different subject matters that coexist in CM.
>>>>>>
>>>>>>
>>>>> I wouldn't count that rule "*all* modules must be released" as a
>>>>> mantra:
>>>>>
>>>>>
>>>> I found the idea attractive, but Stian (link to older discussion
>>>> in a previous post) advised that maven would not easily "support"
>>>> it.
>>>>
>>>> Has that changed since the discussion took place (10 months ago)?
>>>>
>>>> a) In case of an emergency release (fixing a CVE, for example), I'd
>>>>
>>>>> clearly consider pushing out the module as more important than waiting
>>>>> for a full release. (Of course, one must be careful to maintain
>>>>> compatibility when pushing out just a module, but that goes without
>>>>> saying.)
>>>>> b) I'd like to hear others experiences on that topic (maybe VFS).
>>>>> Anyways, my personal experiences with Rat are clear: Releasing *all*
>>>>> together is causing nothing but pain, and tends to defer releases
>>>>> indefinitely. OTOH, releasing a submodule can be done at all times,
>>>>> and without overly much preparation.
>>>>>
>>>>> In conclusion, I'd definitely support the release of a single
>>>>> submodule, if the need would arise.
>>>>>
>>>>>
>>>> How can one reconcile what you say here with what was said in
>>>> that old thread?
>>>>
>>>> Would the PMC accept that a component contains independent modules
>>>> (where "independent" means that each module can have its own version
>>>> number, irrespective of the component's version)?
>>>>
>>>> Arguably (cf. thread referred to above), a "Commons" component
>>>> should be simple enough that multiple versions are not necessary.
>>>> [Chorus:] This is not the case with "Commons Math", hence separate
>>>> components for independent contents (such as "Geometry", "RNG",
>>>> "Numbers" and "SigProc") is the simplest solution.
>>>>
>>>> Gilles
>>>>
>>>> Jochen
>>>>
>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [hidden email]
>
> For additional commands, e-mail: [hidden email]
>



--

---------------------------------------------------------------------

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
In reply to this post by Amey Jadiye
On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote:

> On Fri, Dec 1, 2017 at 6:56 PM, Gilles <[hidden email]>
> wrote:
>
>> Hello Amey.
>
>
> Hi Gilles,
>
>>
>>
>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>
>>> Pardon me for pulling this thread up again, I havent read anything
>>> about
>>> "Commons Geometry" since long
>>>
>>
>> Thanks for your renewed interest.
>>
>> (or may be I missed any other disscussion? ).
>>>
>>
>> Probably not.
>>
>> is someone working on this ?
>>>
>>
>> It would be a surprise.
>>
>> what is the final decision ?
>>>
>>
>> There hasn't been any progress towards a decision.
>>
>
> I'm not sure if "Lazy Consensus" works in these matters ? better take
> help
> of it, its fast and easy.

By definition, it does not apply when people voice their opinion:
Some did it one way, others did it in another (non-compatible way).

The strange thing here is that some PMC members seem to prefer
moving Commons Math to "dormant" rather than let the few remaining
active developers do some cleanup in the hope to revivify some of
the code base in a more modern Java eco-system.

Gilles

> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Martijn Verburg
Has the PMC and the active developers met over a video call to try and hash
this out?

It would be a shame to see this library fall into disuse.

I'd also argue with Jigsaw being the heart of Java 9+ that more modular
libs now make sense.

Cheers,
Martijn

On 1 December 2017 at 14:56, Gilles <[hidden email]> wrote:

> On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote:
>
>> On Fri, Dec 1, 2017 at 6:56 PM, Gilles <[hidden email]>
>> wrote:
>>
>> Hello Amey.
>>>
>>
>>
>> Hi Gilles,
>>
>>
>>>
>>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>>
>>> Pardon me for pulling this thread up again, I havent read anything about
>>>> "Commons Geometry" since long
>>>>
>>>>
>>> Thanks for your renewed interest.
>>>
>>> (or may be I missed any other disscussion? ).
>>>
>>>>
>>>>
>>> Probably not.
>>>
>>> is someone working on this ?
>>>
>>>>
>>>>
>>> It would be a surprise.
>>>
>>> what is the final decision ?
>>>
>>>>
>>>>
>>> There hasn't been any progress towards a decision.
>>>
>>>
>> I'm not sure if "Lazy Consensus" works in these matters ? better take help
>> of it, its fast and easy.
>>
>
> By definition, it does not apply when people voice their opinion:
> Some did it one way, others did it in another (non-compatible way).
>
> The strange thing here is that some PMC members seem to prefer
> moving Commons Math to "dormant" rather than let the few remaining
> active developers do some cleanup in the hope to revivify some of
> the code base in a more modern Java eco-system.
>
> Gilles
>
> [...]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
Hi.

On Sat, 2 Dec 2017 20:40:38 +0000, Martijn Verburg wrote:
> Has the PMC and the active developers met over a video call to try
> and hash
> this out?

The ML archive is replete with discussions.
A few PMC members voiced their agreement with the Apache mantra.
A few oppose trying an approach that would break the status quo,
even as it has stalled development (the next major release is
nowhere in sight, almost 3 years after work started on it).

> It would be a shame to see this library fall into disuse.

The library can be used but is virtually unmaintained.

IMO, the question is why the loss of continuity is being preferred
over a proposal that costs only to those who are willing to put
work in it.
The asymmetry of the situation should be obvious...

> I'd also argue with Jigsaw being the heart of Java 9+ that more
> modular
> libs now make sense.

+1 to a separation of concerns that allows for clear and independent
lines of development.

Regards,
Gilles

> Cheers,
> Martijn
>
> On 1 December 2017 at 14:56, Gilles <[hidden email]>
> wrote:
>
>> On Fri, 1 Dec 2017 19:23:57 +0530, Amey Jadiye wrote:
>>
>>> On Fri, Dec 1, 2017 at 6:56 PM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>> Hello Amey.
>>>>
>>>
>>>
>>> Hi Gilles,
>>>
>>>
>>>>
>>>> On Thu, 30 Nov 2017 23:45:45 +0530, Amey Jadiye wrote:
>>>>
>>>> Pardon me for pulling this thread up again, I havent read anything
>>>> about
>>>>> "Commons Geometry" since long
>>>>>
>>>>>
>>>> Thanks for your renewed interest.
>>>>
>>>> (or may be I missed any other disscussion? ).
>>>>
>>>>>
>>>>>
>>>> Probably not.
>>>>
>>>> is someone working on this ?
>>>>
>>>>>
>>>>>
>>>> It would be a surprise.
>>>>
>>>> what is the final decision ?
>>>>
>>>>>
>>>>>
>>>> There hasn't been any progress towards a decision.
>>>>
>>>>
>>> I'm not sure if "Lazy Consensus" works in these matters ? better
>>> take help
>>> of it, its fast and easy.
>>>
>>
>> By definition, it does not apply when people voice their opinion:
>> Some did it one way, others did it in another (non-compatible way).
>>
>> The strange thing here is that some PMC members seem to prefer
>> moving Commons Math to "dormant" rather than let the few remaining
>> active developers do some cleanup in the hope to revivify some of
>> the code base in a more modern Java eco-system.
>>
>> Gilles
>>
>> [...]
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

jochen-2
In reply to this post by Gilles Sadowski
On Fri, Dec 1, 2017 at 2:26 PM, Gilles <[hidden email]> wrote:

> There hasn't been any progress towards a decision.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).

Those who do the work are welcome to decide on their own, if they do
not involve others. Establishing a new commons component doesn't
qualify, IMO.

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Gilles Sadowski
On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <[hidden email]>
> wrote:
>
>> There hasn't been any progress towards a decision.
>> There isn't even a consensus on one of the central tenets of
>> Apache ("Those who do the work..."): how sad/strange (?).
>
> Those who do the work are welcome to decide on their own, if they do
> not involve others.

The conditional is not part of the well-known mantra.

The issue here is to answer the question of what to do with
a non-trivial code base.  My stance is to try and fix the
problem(s), a.o. difficult management, by rooting out its
main cause: CM has become an aggregate of components with
completely different subject matters, scopes, designs,
efficiencies, provisions for extension, etc.
[An array of issues which "maven" modules will not solve.]

We are seemingly faced with a choice between:
1. Maintain CM as the huge library that it is now.
2. Incrementally create maintainable components.

A long time has passed since these alternatives were first
exposed, only proving that none of the people who informally
chose option(1) invested work to make it a reality.

Refusing option (2) not only "involves others"; it is harming
them (very real people, having done a lot of work here, on
that code base).

> Establishing a new commons component doesn't
> qualify, IMO.

True; that's why we are stalled, despite that a majority
of the PMC did not explicitly oppose option (2).

A handful of PMC people prefer to let the code base become
"dormant" rather than give any chance to an alternate view.
[If, say, you looked at the "Commons RNG" project, and
concluded that, decidedly, this is not how a component
should look like, then I could perhaps fathom out where
those reservations come from.]

Gilles

>
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Martijn Verburg
Can this project be forked to a new domain over on GitHub (under the
existing Apache license), split up and then continued in that case?

Cheers,
Martijn

On 3 December 2017 at 11:51, Gilles <[hidden email]> wrote:

> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>
>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <[hidden email]>
>> wrote:
>>
>> There hasn't been any progress towards a decision.
>>> There isn't even a consensus on one of the central tenets of
>>> Apache ("Those who do the work..."): how sad/strange (?).
>>>
>>
>> Those who do the work are welcome to decide on their own, if they do
>> not involve others.
>>
>
> The conditional is not part of the well-known mantra.
>
> The issue here is to answer the question of what to do with
> a non-trivial code base.  My stance is to try and fix the
> problem(s), a.o. difficult management, by rooting out its
> main cause: CM has become an aggregate of components with
> completely different subject matters, scopes, designs,
> efficiencies, provisions for extension, etc.
> [An array of issues which "maven" modules will not solve.]
>
> We are seemingly faced with a choice between:
> 1. Maintain CM as the huge library that it is now.
> 2. Incrementally create maintainable components.
>
> A long time has passed since these alternatives were first
> exposed, only proving that none of the people who informally
> chose option(1) invested work to make it a reality.
>
> Refusing option (2) not only "involves others"; it is harming
> them (very real people, having done a lot of work here, on
> that code base).
>
> Establishing a new commons component doesn't
>> qualify, IMO.
>>
>
> True; that's why we are stalled, despite that a majority
> of the PMC did not explicitly oppose option (2).
>
> A handful of PMC people prefer to let the code base become
> "dormant" rather than give any chance to an alternate view.
> [If, say, you looked at the "Commons RNG" project, and
> concluded that, decidedly, this is not how a component
> should look like, then I could perhaps fathom out where
> those reservations come from.]
>
> Gilles
>
>
>> Jochen
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [All][Math] New component: "Commons Geometry"?

Ralph Goers
In reply to this post by Gilles Sadowski
I don’t know why you are ignoring option 3, which is what many have suggested many times.
3) Modify CM to be a multi-module project that contains only the modules you want to support.

Ralph

> On Dec 3, 2017, at 4:51 AM, Gilles <[hidden email]> wrote:
>
> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <[hidden email]> wrote:
>>
>>> There hasn't been any progress towards a decision.
>>> There isn't even a consensus on one of the central tenets of
>>> Apache ("Those who do the work..."): how sad/strange (?).
>>
>> Those who do the work are welcome to decide on their own, if they do
>> not involve others.
>
> The conditional is not part of the well-known mantra.
>
> The issue here is to answer the question of what to do with
> a non-trivial code base.  My stance is to try and fix the
> problem(s), a.o. difficult management, by rooting out its
> main cause: CM has become an aggregate of components with
> completely different subject matters, scopes, designs,
> efficiencies, provisions for extension, etc.
> [An array of issues which "maven" modules will not solve.]
>
> We are seemingly faced with a choice between:
> 1. Maintain CM as the huge library that it is now.
> 2. Incrementally create maintainable components.
>
> A long time has passed since these alternatives were first
> exposed, only proving that none of the people who informally
> chose option(1) invested work to make it a reality.
>
> Refusing option (2) not only "involves others"; it is harming
> them (very real people, having done a lot of work here, on
> that code base).
>
>> Establishing a new commons component doesn't
>> qualify, IMO.
>
> True; that's why we are stalled, despite that a majority
> of the PMC did not explicitly oppose option (2).
>
> A handful of PMC people prefer to let the code base become
> "dormant" rather than give any chance to an alternate view.
> [If, say, you looked at the "Commons RNG" project, and
> concluded that, decidedly, this is not how a component
> should look like, then I could perhaps fathom out where
> those reservations come from.]
>
> Gilles
>
>>
>> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234