On Tue, 27 Dec 2005, Phil Steitz wrote:
Henri Yandell wrote:
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].
Thanks again. So the real problem is disjointness. It seems then that
we have three logical alternatives:
0) Full disintegration - all projects (incl j-c) become TLPs or die and
Jakarta effectively dies as a concept.
1) Commons or bust - lump small components (e.g. BCEL, ORO) into j-c
and move the others (e.g. Tapestry, Jmeter, Cactus) to TLP. Keep
jakarta-general around and the Jakarta site for general Java
community-building across apache.
As Brett pointed out, this is really 0). I effectively a) don't want to
mess around with the commons.apache.org conversation again and b) think
there is a real synergy between Jakarta Commons and Java Federation.
2) Re-aggregate - divide Jakarta up into a small number of cohesive
aggregates. Its not clear to me how this would work or if this kind of
encouraged merging is a good idea; but it is logically the same sort
of thing that you are hinting at in 1).
Yep, this is a further idea I'd mentioned somewhere but I forget where.
Folding into Commons means an increase in noise, though the ones that
would get folded in aren't that noisy. Largely they're ones that members
of the Commons community are already juggling, or whose single committer
would really benefit from the shared community.
However, I think if we find the noise too much, then we can group things.
They're categorically not subprojcts, just groupings. HttpClient is
already heading this way, it's now the HTTP-Group of Jakarta Components,
with a little bit of artistic license on my part :)
Silk would be the Web-Group of Jakarta Components [I've been unable to get
anything firm on the Silk name, so for the last few weeks I've put it on
the backburner as this series of ideas would trump it].
ORO, Regexp and Codec form a natural group. However they're not noisy so
they would remain on the commons-dev/commons-user mailing lists. It'd be a
bit confusing, but I'd like to set it up so that if a grouping goes quiet,
it is directed towards rejoining the main list.
We do have a problem with noise, and I think we need to try some new ideas
out. Like setting up Jyve at long last :) I sat with a Jyve developer at
ApacheCon and he did a good job of answering the usual problems with
handling a forum side by side with a mailing list.
Another is to come up with a better way of monitoring svn, wiki and
jira/bugzilla changes. Maybe we could aggregate them into reports?
0) seems a shame from the Java community and Jakarta brand (whatever
that means) standpoint; but may be the most reasonable thing to do. My
concern with 1) is that j-c is already having trouble scaling and I am
not so sure that once things are merged in (or out) there is anything
substantial left for Jakarta to be (i.e., I am having a hard time
seeing the real practical difference between 0) and 1)). I have to
The big one is the hopeful synergy between Jakarta as a federation and
Jakarta as a commons. You can tell I'm in sales mode, I've said that word
twice now.
On a larger scale, I think this might be a nice pattern for the ASF.
Federations who manage just the shared components as a Commons, while also
being the shared conversation place.
confess to having no idea how to do 2), but maybe others in the
community do - ideally people working on projects that might want to
aggregrate.
There's a bit of that; I'm hoping Cactus and JMeter would form a
testing.apache.org if they so choose; but largely I can't see a lot of
aggregation reasons. Apart from creating TLPs that are all tiny Commons
groupings, which just splits up the parts of shared community we do have.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
