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. Stephen [1] https://marc.info/?l=jakarta-commons-dev&m=108601577728628&w=2 [2] http://commons.apache.org/oldcharter.html (item 15) On 6 December 2017 at 12:59, Gilles <gil...@harfang.homelinux.org> 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 <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
