commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject [plea] get back to work -- was Re: [codec] [proposal] Moving To Apache Commons
Date Tue, 23 Dec 2003 01:00:02 GMT
Daniel F. Savarese wrote:
> In message <>, Ga
> ry Gregory writes:
>>Well, now I am switched around to a "-1" as well :-(
>>>From: Rodney Waldhoff 
>>>1) a-c organization: I think the organizational structure of
>>>apache-commons (one list per component, balkanized karma rights, etc.) is
>>>bad for those components technically and socially, and possibly bad
>>>for the ASF from an oversight perspective.
>>I am not that familiar with a-c but I would prefer to keep all of the
>>Jakarta commons in one lump as much as possible. It is nicer to work and
>>explore in just one place, and perhaps offers more opportunity for
>>cross-pollination between components.
> I think something folks are missing is that if J-C moves to A-C, then
> all J-C committers become A-C PMC Members and can change the rules that
> don't make sense once A-C has incorporated J-C.  For example, and it's
> only a hypothetical for expository purposes and not a suggestion, we
> could create a list for components geared
> toward supporting Jakarta projects instead of using per component lists.

And what exactly would that buy us beyond what we have now in Jakarta Commons?

> ASF projects aren't implemented in a top-down fashion.  They evolve
> to meet changing needs.  The A-C organization will change accordingly

As mentioned repeatedly on this and other threads, there are many of us 
who view the Java-centric nature of Jakarta Commons as central to its 
definition and strength.  That does not make us language bigots or "bad 
Apache citizens."  It just means that we value the community that has 
grown around the Java components in Jakarta Commons and we would like to 
keep that community intact.

I find it ironic that this whole discussion is motivated in part by 
concern for oversight.  At least from a technical perspective, the 
oversight that the Jakarta Commons components get in this environment is 
much better than they would if j-c were broken up.  If we were to combine 
all of the Apache Commons projects (Jakarta, DB, XML, etc) together, the 
effectiveness of that community oversight would be much less, IMHO.  As a 
j-c committer and Jakarta PMC member, I view it as my responsibility to 
monitor commons-dev and commons-user carefully.  It would be *much* harder 
for me to do that in a generic commons environment.  The result would 
inevitably be segregation by technology or component type, which would 
lead to "Apache Commons" facing the same problems that "Apache Jakarta" is 
now.  For Jakarta Commons, the best that we could hope for is a period of 
uncertainty ending in more or less the same structure that we have now.

I agree with your statement in another post that none of this is likely 
going to be resolved without a vote.  Since I am not among the "dissolve 
Jakarta" camp, I am certainly not going to be the one to propose it; but I 
wish that we could put this subject to bed.  Either we dismantle Jakarta 
and force j-c to go TLP (preferred option, IMHO if necessary) or merge 
with Apache Commons, or we focus our efforts on moving Jakarta and j-c 

So here is my plea.  Either someone propose a [VOTE] to force all Jakarta 
components to merge with existing TLPs or become TLPs or we (Jakarta 
community) get back to work on fixing the following problems:

1. Signed CLAs from all committers
2. All active committers join the Jakarta PMC
3. Define oversight responsibilities for Jakarta PMC members in general 
and for j-c in particular, ensuring that we have sufficient oversight for 
each j-c component
4. Fix the j-c web site, agreeing with infrastructure@ on what needs to go 
in CVS (short term and long term) and when and how we "mavenize"
5. Get released versions out for all components that other Apache projects 
depend on
6. Update the j-c charter and release process docs to reflect current 
7. Everything else that I forgot :-)


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

View raw message