Divinding J-C

[Stephen Colebourne <sc...@btopenworld.com>]

> My mail system would undoutably be better off with multiple lists. But j-c
> may suffer. This is a dilema. It would be nice if there was a clear
division
> into two or three that could occur, but finding it causes problems.
>
There MAY be potential to divide j-c into two separate Jakarta projects,
'core' and 'utility'. The division I see based on level in an (example)
application stack:

User application
Struts etc.
Utility
Core

Thus utility depends on core jar files, but not vice versa. In fact, core
jars generally depend on nothing but the JDK. The utility level components
also tend to have more 'religion' about them (ie. you have to take more time
to learn them, and to fit into their ways).

This kind of division would give j-c more sensible traffic on the lists,
hence more sensible and clear oversight. Because the division is only into
two, there should be enough people about to populate each sufficiently.

Well, its an idea (and probably should go to j-c list ;-)
Stephen

----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: <ge...@commons.apache.org>
Sent: Thursday, November 13, 2003 1:05 AM
Subject: Re: J-C oversight (was: Benefits of Apache Commons)


> From: "robert burrell donkin" <rd...@apache.org>
> > jakarta-commons is high traffic but the worries about scalability are
> > not to do with supervision but whether normal developers can continue
> > to be attracted.
>
> I've been quiet for a while, but I wanted to agree with this last
statement.
> Its not about supervision in j-c, but keeping attracting new ideas and
> committers.
>
> I would suggest
> a) the j-c mailing list is very high traffic
> b) some newcomers/contributers are definitely being put off by this
> c) the ability for j-c to accept new components must eventually be limited
> by the one mailing list arrangement
> d) j-c is very well supervised
> e) committed coders are in charge of their components
>
> Stephen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>