I'm sorry to say that this mail demonstrates there is still a misunderstanding about how jakarta-commons works and its goals.
The answer to the question "how would a Jakarta Commons TLP differ from an Apache Commons TLP?" is simple. The only difference would be that J-C does focus on java and A-C also includes other languages.
J-C has demonstrated in the past that it can build community around components from other ASF projects. Not only the original authors are giving support but new comitters joined as well. Individual components can have their own dedicated functional mailing lists if needed or can graduate and move outside J-C like cactus did.
Personally I think all java components should stay together in J-C and not some components here, some at A-C, DB-C or any other "java" component commons look alike (sub)project.
You can ask the question why not move everything to A-C? Let me answer with another question: Why should we?
I have followed most of the discussion on [EMAIL PROTECTED] and cannot find a reason to move over. A functional split of the mailing lists is a nice idea but also impractical. One list for each programming language is easier.
While subversion is technically better, cvs is also easier. There are of course tools for both but take a tomcat or struts committer. If their commons component live in a subversion system then they need 2 sets of tools to build their projects. I don't know it maven and gump are subversion ready but there are also the scripts people run to do the nightly builds and other standard tasks.
When all of the ASF switches to subversion (and there is more native tool support) then we will see the benefits but for the time being cvs is good enough IMHO.
Same with the main A-C website, here at J-C we are moving toward a maven build system for everything.
All these issues can be resolved of course. But the question remains: Why should we invest time and energy in trying to fix something that isn't broken?
Let us invest in handling some real improvements: merge to one wiki system, switch to the new issue tracking system (JIRA), the repository project for distributing binaries, dedicated integration/nightly build system, automated website build system (forrest/maven-bot), website backup strategy.
Of course maybe there are problems that I don't see, if so please enlighten me.
This mail is already far too long but to come back to my previous mail. I think we should make a clear distinction between groups formed for legal reasons (oversight) == PMC, groups formed around a piece of code (for example tomcat comitters), groups formed around the same interests (for example: jakarta brand) and of course the whole Apache group as a way of living ;-)
I have the impression that the oversight issue that started all of this is growing into something threatening the community just because we try to force everything into one structure while the real need is for multiple structures. A legal one, interest groups and of course groups for cultivating community/brands like jakarta. But that is another personal opinion.
regards Dirk
Justin Erenkrantz wrote:
--On Saturday, December 20, 2003 4:20 PM +0100 Dirk Verbeeck <[EMAIL PROTECTED]> wrote:
Maybe Jarkarta should take up the role of a [EMAIL PROTECTED] gatekeeper.
Something like the java foundary at sourceforge but with the additional task
to bring all the (independent) java communities together and provide a
vision for the [EMAIL PROTECTED] future.
For those of you that don't know me, hi, I'm currently Apache Commons PMC chair. Nothing I am saying here is binding as it's my personal opinion. As an ASF member, my only desire is for all ASF codebases to be given the opportunity to succeed - if it's in Apache Commons or not, that doesn't matter to me as long as the code has a chance to succeed within the ASF.
One of the comments that I have seen in this thread is that J-C is a package deal - that J-C shouldn't be split up - all of the J-C projects should share the same fate. Please allow me to put forth some commentary on this.
I believe one of the prime motivations for the ASF is that the people who are doing 'stuff' get a say in 'how' stuff is achieved (meritocracy). This is the main rationale behind the PMCs and TLPs - they should be composed of people who are actively contributing and providing direction and guidance to a project.
However, an essential aspect of this guidance is motivated by the codebases involved. So, what direction and guidance can be provided by a Jakarta Commons TLP? The Apache Commons PMC has discussed how the Apache Commons can provide this direction and guidance at some length, so please let me provide our insights into this - perhaps it'll help frame your discussions. The question I'd like to keep in the back of your minds is how would a Jakarta Commons TLP differ from an Apache Commons TLP?
Apache Commons has two desires: 1) build communities that can manage themselves around reusable codebases initially created *within* the ASF; 2) support smaller-scale projects that might not garner enough community interest to justify being a TLP but still worthy of the ASF's involvement.
The Apache Commons PMC has maintained that when a community gets 'big' enough (or groupings of components can be composed as one TLP logically), we're going to ask the involved committers (who'll be on the Commons PMC) to form a new TLP and stand on its own. We believe there is no fundamental reason to keep projects that could manage themselves from doing so. There are several Apache Commons PMC members that have been involved in the formation of TLPs within the ASF and can help communities realize when it's time even though they themselves may not yet realize they are 'ready' as they haven't been involved in the creation of TLPs before.
On the other hand, I honestly expect the fate of a fair number of the components in Apache Commons to be that they achieved their goal successfully. In this respect, Apache Commons would be very different than other TLPs which aren't supposed to have an easily attainable goal. There's only so many ways to write a regex library. Once it's done, there doesn't *have* to be much more work. So, the policies and procedures adopted by Apache Commons PMC is geared towards supporting a large number of reusable components and sharing between them. (This is one of the many reasons why Subversion was chosen for Apache Commons before the rest of the ASF switches to Subversion.)
Now, what happens when projects leave a 'community' (i.e. a codebase becomes part of a TLP) - do they really leave? What's to stop people from being active in a number of different communities? I think you'll find that a lot of ASF members are involved in multiple open-source communities (both inside and outside of the ASF!). As you get involved with open-source projects, you'll find that you're going to run into a lot of familiar faces and then some not-so-familiar faces. I believe cross-pollination is wonderful.
From my outsiders' perspective, this cross-pollination is present to some
extent here in Jakarta Commons already (yay!), but I think there's a reluctance to admit that this mailing list is really many different communities at work - every [subject] line group *is* a different community! There may be a lot of overlap between these communities and these communities may be small in size, but I believe each one should be able to direct itself according to their independent wishes.
I know there's a lot of worry at the thought of partitioning J-C into codebases that may live in multiple TLPs or even in Apache Commons, but I'd just like to introduce some of the possible benefits and advantages of doing that. It may seem scary to many at first, but I think the end result is far stronger communities. Thanks! -- justin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
