commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [All][Math] New component: "Commons Geometry"?
Date Wed, 06 Dec 2017 15:28:35 GMT
Frankly, as an observer, this issue seems to be handled pretty poorly.
Commons-Math is currently dead. There are people willing to put in
effort to work on parts of it, but they are blocked at every turn.
Various options are put forward, but nothing ever happens.

In technical terms, if Commons-Math were a TLP, it would no doubt
release multiple separate releases, just like commons does. Thus,
separate commons projects seems like a good model.

Commons-VFS is not a good comparator, as it is a single "narrow and
deep" library with plugins. Commons-Math is a "broad and shallow"
library by comparison [1]. Subdivisions of a "broad and shallow"
library are best managed with separate release cycles, as each part is
independent of the others. (commons [lang], [collections] and [io] are
not forced to be multi-module simply because they all release to the
java.base module).

Anyway, the original rules for Commons [2] required a majority
approval vote (more +1 than -1) to create a new component, which has
already happended AFAICT. So, I think those that want to create a new
component should JFDI.


[2] (item 15)

On 6 December 2017 at 12:59, Gilles <> wrote:
> Hi Ralph.
> On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:
>> I don’t know
> Then please _read_ the ML archive.
>> why you are ignoring
> I do not (willingly) "ignore" any proposal. [Gentle
> reminders are welcome if/when I lost track of a pending
> issue that is waiting for my input.]
> It's rather the opposite: a few PMC people keep turning
> a blind eye to arguably constructive proposals (see below
> and ML archive).
>> option 3, which is what many have
>> suggested many times.
> With strings attached. See ML archive.
>> 3) Modify CM to be a multi-module project
> See below; what don't you understand in "issues which
> maven modules will not solve"?
> [See ML archive for a many times reiterated detailed
> description of the CM problems, the difference between
> CM and other components (modular or not), here and
> elsewhere, and how we do not have (never had) the human
> resources to correctly handle such a large and diverse
> code base.]
>> that contains only the
>> modules you want to support.
> That condition was explicitly rejected  when *I* first
> evoked it (see ML archive).
> Later discussions (see ML archive) clarified (?!) that
> modularizing CM would certainly not suffice to revive
> the project.
> Other options were (see ML archive)
> 4. create an Apache TLP (proposed by James Carman),
> 5. go through the Incubator.
> Either one required the PMC to relinquish the code base
> (no internal fork allowed IIUC), which it refused (see ML
> archive).
> The now visible consequences of renewed obstruction to
> the refactoring of CM were not difficult to predict (see
> ML archive).
> Gilles
>> Ralph
>>> On Dec 3, 2017, at 4:51 AM, Gilles <> wrote:
>>> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
>>>> On Fri, Dec 1, 2017 at 2:26 PM, Gilles <>
>>>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message