2) One sub-project for each component ignoring language (eg. commons.apache.org/collections). But then what happens if that component is implemented in two languages?
IMHO, it would then be up to the component to create divisions internally based on language.
That is:
commons/httpclient
could initiallty start out with the codebase from apr-serf. If the httpclient from Jakarta wants to come over, then the serf committers and the httpclient committers can duke it out. But, the httpclient is their collective place to play. It's their responsibility to sort out the code divisions. (I would probably suggest commons/httpclient/serf, commons/httpclient/java, but I don't really care to think about it until it happens.)
(A SCM that supported moving of directories and files would be real nice. Heh. I wonder...)
This affects many things - how the mailing lists are structured, how the website is structured, how the communities will form, etc.
As we have discussed before, I believe we are going to stick with a single email list for all of commons. If/when a particular group takes over the mailing list, someone could suggest a new mailing list to be created. (I'd say majority of the participants on the list get to decide if the new list should be created.)
I prefer that we evolve the infrastructure rather than hash out an infrastructure from the beginning. -- justin
