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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to