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]