On 5/25/07, Ted Husted <[EMAIL PROTECTED]> wrote:
On 5/23/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> In fact, I object to the fact the it seems to be so difficult to escape 

:) So far, it's been *much* less difficult than creating the Jakarta
Commons in the first place! Back in the day, we actually had a
separate mailing list just for for the discussions about whether to
create the subproject, and how it would work if we did! :)


So far, the TLP resolution quickly passed by a landslide. Two of us
had reservations about an "Apache Commons" project that's devoted to
Java, as opposed to an "Apache  [Java|Jakarta|Mocha|J] Commons" that's
devoted to Java. There were two other negative votes for different
reasons, and almost thirty votes in the affirmative.

Meanwhile, some of us have pointed out that the other remaining
subprojects are within the scope of the Jakarta Commons, and have
wondered if these subprojects would now like to join the commons. Of
course, that could happen before or after the proposed resolution is
offered to the board. But, if it did happen first, that change would
remove any complaint as to using Apache Jakarta Commons as a project

From the beginning, the intent was to submit the proposed resolution
to the June board meeting. There's time yet to see if the other
subprojects want to join, so nothing is being delayed.


I think we're at a point of needing to offer options to the subprojects:

1) Go TLP (or other TLP)
2) Stay for Jakarta2 (see below)
3) Goto the Incubator - I know this is a very disliked option, but
it's better than the only other option I can think of:
4) Goto code.google. Ack :(

I admit to thinking that the three big question marks in terms of
living in a flattened dev@ list for me are Slide, JMeter and Cactus.
I'm willing to be +1 to them being in a flattened Jakarta2 with an eye
to sending them TLP if we can build community. It's effectively the
Jakarta2 community incubating them, but if it helps things move on...

Jakarta2 - A flattened commons-like umbrella which in terms of change
means a flattened dev@ list and svn changes. What I don't know is
whether people are going to be demanding that the subsites look the
same; ie) need to mavenize each project and adjust the site. The
easiest way to deal with things will be to move the other subprojects
into Commons and reestablish the Project.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to