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 <gil...@harfang.homelinux.org>
wrote:
On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles
<gil...@harfang.homelinux.org> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
