In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] 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 forward.
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 practices
7. Everything else that I forgot :-)
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
