jakarta future WAS: Re: Starting a java specs project (fwd)

[Phil Steitz <ph...@steitz.com>]

Henri Yandell wrote:
> 
> 
<snip/>
>> 
>> 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.

Nice definition. Thanks.
<snip/>
> 
> 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.

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).

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
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."

Phil



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: jakarta future WAS: Re: Starting a java specs project (fwd)

[Henri Yandell <ba...@generationjava.com>]

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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: jakarta future WAS: Re: Starting a java specs project (fwd)

[Henri Yandell <ba...@generationjava.com>]

On Wed, 28 Dec 2005, Brett Porter wrote:

> Thinking more about this, I don't know about "pushing things into
> commons". The important thing is consistent practices, consolidated
> committers and community, but maybe not the naming. Jakarta BCEL
> sounds fine to stay that way, as does Jakarta Commons Collections.

I was originally thinking it would be more like Jakarta Collections than 
Jakarta Commons BCEL. But a good point, the naming is not a biggy. It'd be 
pretty loose I think, the same way Tomcat was Apache Tomcat even while it 
was still in Jakarta. Commons is a community and a way, rather than just 
an svn directory.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: jakarta future WAS: Re: Starting a java specs project (fwd)

[Brett Porter <br...@gmail.com>]

Hi Phil,

On 12/28/05, Phil Steitz <ph...@steitz.com> wrote:
> Thanks again. So the real problem is "disjointness."  It seems then that
> we have three logical alternatives:

I don't think there is a lot of difference any of these. Jakarta
commons as a TLP is basically (1)  as well. There are definitely some
details to sort out, but they are all along the same track.

Thinking more about this, I don't know about "pushing things into
commons". The important thing is consistent practices, consolidated
committers and community, but maybe not the naming. Jakarta BCEL
sounds fine to stay that way, as does Jakarta Commons Collections.

For scalability, I don't see there is a problem dealing with that in
the near future in commons-user or commons-dev (if the notifications
from SVN, JIRA, Gump, etc go to a different list). List traffic seems
the only barrier here - but I think these are issues to deal with
during growth, not up front.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org