On Tue, 7 Mar 2006, Stephen Colebourne wrote:

Thomas Dudziak wrote:
Could you elaborate a bit on what the physical / visual-to-users
differences to the current commons, well, Jakarta sub-project will be
? Will this be a new Jakarta sub-project (and the other commons
components will remain in the current commons one) ?

I've been trying to dodge this question. Why? Because I want to encourage other groupings (especially from commons) to self-select. If I make a proposal, then it will be an imposition.

My hope is that in a few months we will have a mentality of working on *Jakarta* components, not working on commons (or any other) components. To achieve this will require other groupings.

Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and Velocity, may have real issues with this whole grouping philosophy. My answer is to *not* force communities that are truly content with the status quo to change.

If the status quo is that they can be independent subprojects without having to pay attention to the rest - then I'm going to eventually be forcing it - if they want to be a TLP, they can be a TLP. The only alternative I see to that is that Jakarta as a whole declares that it wants to be an umbrella and we'll go to the board with that.

How POI, Velocity and Turbine fit into things is definitely still up
for grabs. Velocity and Turbine both contain components - making them groupings already - so it wouldn't be a huge change for them to treat those components as top-level Jakarta components within a particular grouping.

ie: Fulcrum is a component in Jakarta within the Turbine grouping.

Each grouping will have: - a bland name (Jakarta Xxx Components)

+1.

- an identity (how and why does the group exist)

+1

- sufficient size (to be active not inactive)

+0. Not too concerned about an inactive grouping - as long as we

- mailing lists (one ML for all Jakarta doesn't work)

+1

- SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED]

Not sure what the differentiation between [EMAIL PROTECTED] and [EMAIL PROTECTED] would be. +1 to sharing common issues - an as you know I'd like to take that a bit further to issues that they have in common (ie both have svn reorg issues, even if different bits of svn).

I'd like to add:

* Groupings are NOT reflected in svn. jakarta/lang/trunk not jakarta/jlc/lang/trunk.

What I will say is that its too early to worry about website issues. For now, all we need to know is that there will be a link somewhere to each component, and probably a single page describing each group. Pages such as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED]

+1.

I'd also like us to avoid the word charter when discussing the description for a grouping.

Hen

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

Reply via email to