On Tue, 27 Dec 2005, Phil Steitz wrote:
Henri Yandell wrote:
An FYI. Please kick me if I'm going too far with these ideas; I get the
feeling I have a general +0, but hard to tell sometimes.
See interspersed. I am not quite to the "+" point yet, but probably either
just missing some concepts / principles or interested in understanding better
what the alternatives are.
Answers inline. Thanks for the reply, this is the first time I've probably
listed all of these bits together as a strategy, so I apologise for any
surprise.
---------- Forwarded message ----------
Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST)
From: Henri Yandell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: general@incubator.apache.org
Subject: Re: Starting a java specs project
One idea was to collate them as a part of Jakarta.
My aim for Jakarta is to either promote subprojects to TLP or flatten them
into Jakarta Commons,
The risk there is j-c becoming the new "umbrella." We are also having enough
trouble scaling j-c now.
leading to a non-umbrella Jakarta
It would be great if we could get a consensus on what an "umbrella" is and
An umbrella is a joining of disjoint communities under a common TLP. A
non-umbrella is one in which the whole project is a part of the same
community.
That's a nicely grey definition :) It allows for things to be becoming
less non-umbrella and more umbrella. ie) Struts now has two subprojects
and their concern is to make sure that they stay focused on the one
community.
what is bad about it. I don't want to open too many cans of worms here; but
not all of us were around for the "good old bad old days" of Jakarta. It
seems to me that all of the following could now be considered "umbrellas" in
some sense, but we (apache) seem to be collectively OK with them:
Some of the below are definitely listed as 'heading that way', but I don't
want to get mired down in that, it's the boards worry as to when they
become too much umbrella and too little single-community.
Geronimo
Web Services
XML
Struts
DB
Logging
Portals
But somehow Jakarta is "too big." If you look at all of the code now coming
I don't think Jakarta's considered too big anymore. A lot of this is being
driven by my wanting to rekindle the positive sides of the old Jakarta,
and wanting to finish what was started. It might be the librarian in me,
but the current state of Jakarta has no raison d'etre. It's just a clump
of legacy.
The biggest problem with Jakarta currently is that we've become
increasingly disjoint. In many ways we are less healthy than we were 4
years ago. We have less projects, but much less in the way of intersection
between communities. We've replaced a 7 person sub-board with a single
chair [though there is now quite a clear direction for that single chair].
into Geronimo with the incubations in progress, it will be larger than
Jakarta currently is soon. So why exactly do we need to either mash, e.g.
Hivemind into Commons or move it to TLP? If the answer is "PMC oversight"
then why doesn't that apply to the projects above as well? We have made a
lot of progress - mostly thanks to you, Hen - getting adequate PMC
representation from all Jakarta projects, so I don't see that as such a big
concern any more.
So what problem exactly are we trying to solve by pushing things out or
mashing them into Commons? I don't mean to be argumentative here, I just
want to understand clearly what the goal is and what our acceptable options
are. It would be great to have some principles on what kinds of "aggregates"
(euphemism for "umbrellas" ;-) are OK and what kinds are not. Based on these
principles, we might decide to divide Jakarta differently, creating some
smaller aggregates rather than one big one (j-c) and a string of small TLPs.
One vibrant community, with a future and a reason to exist. A place for
[EMAIL PROTECTED] people to get together and a folding of two (or more) sets of
problems [inactivity, innovation, neutral ground] into a single space
instead of the current multiple spaces. ie) Jakarta has the same problems
with BCEL that Commons has with BeanUtils.
(I know,
you didn't think you'd see it in your lifetime). This new Jakarta would
have the potential to serve two roles:
1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED]
2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons]
While j-c might have begun as 2), this is no longer the whole story, or even
the main story any more.
It's still an important part of the story. Many of our components are
being released in Commons because Struts needs updates etc.
Storing the spec source there would be good for everyone I think; it would
help bring people to Jakarta to share code and conversation, and the
Commons community would make good stewards for the code if the various
owners departed.
We already have too much orphaned code in j-c, IMHO. The advantage of
bringing this stuff to j-c would be bringing in some more active and engaged
committers. This I am sure we would all welcome. Orphaned code we would
not.
I agree, it's a current problem. My reasons for the (rather bombastic I
admit) statement was that a) it's best to locate the problem in one space,
b) j-c has and is working on the problem and c) j-c committers are used to
dealing with the problem.
I don't think bringing the spec stuff in will drive up activity; I'm
assuming spec code, especially this kind, tends to be pretty low in
implementation and there won't be a huge amount of work necessary. Rather
it's about reidentifying Jakarta as the place to share Java at Apache.
If the spec code has more activity, it will bring in developers, but at
the worst it's effects are more secondary.
Maintaining this code will require some specialized expertise most likely
concentrated in projects like Geronimo, Tomcat, etc. If committers from
these projects are interested and willing to sign up to actively support the
code in j-c (including responding to user questions), I am sure we will be
happy to have them join us. I would be hesitant to volunteer the j-c
community, however, as a support mechanism without ongoing active involvement
from the apache projects using the specs, though.
Right. When I say j-c community, I mean the j-c community way instead of
the particular people in the community right now.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
