incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@apache.org>
Subject Re: [STATUS] (commons) Wed Nov 13 23:45:41 EST 2002
Date Thu, 14 Nov 2002 23:59:39 GMT
Greg Stein wrote:
> 
> IMO, no. The sets of committers on some of these components might only
> number two or three. As a Director, I would never +1 a PMC that small.

IMO, we (the ASF) should not be providing areas where people play with 
themselves in public.  Small components should be part of a larger 
community.

> If the components become "too large", then yes: they should spin out. But
> until that determination is made, then a group of reusable components seems
> like quite a fine charter.

+1 on that as a charter.  My concern is on the creation of a fragmented 
community.

> Oh, and in a previous note, you took a comment of mine about Avalon totally
> out of context, and attempted to hold it up relative to Apache Commons. The
> simple answer is that I made a suggestion to the [future] Avalon PMC to not
> divide up the committer/voter base because that kind of partitioning has
> been an encouragement to factionalism. I believe the Avalon community needs
> to learn how to work together, and that means no running off to your own
> area, but to all work in the same box. If the PMC *does* decide to partition
> voters, then fine. They are the people who knows what is best for Avalon --
> I'm only trying to make suggestions on mechanisms which can help patch
> things up. Simply stating, "oh, but we'll try to work together" may not be
> as effective as "everybody gets to vote on that. deal."

The plan seems to be to take components out of the Avalon community and 
bring them to Commons.  Given the concern above, I am not clear how this 
plan addresses the factionalism issue.

> I would also compare/contrast the oversight that can be applied from the
> Apache Commons PMC relative to what has occurred elsewhere. I'm totally
> comfortable knowing that we can have multiple voter/commit realms, *and*
> avoid little fiefdoms or becoming an "uber-umbrella" (I like that term :-).

Seeing it break down in Jakarta and XML, I would like to work in the 
other direction... collapsing voter/commit realms where it makes sense, 
forming new projects where it does not.

> Cheers,
> -g

- Sam Ruby


Mime
View raw message