Return-Path: Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list general@incubator.apache.org Received: (qmail 2407 invoked from network); 14 Nov 2002 23:59:39 -0000 Received: from scandium.sabren.com (209.61.155.99) by daedalus.apache.org with SMTP; 14 Nov 2002 23:59:39 -0000 Received: from apache.org (rdu57-27-066.nc.rr.com [66.57.27.66]) (authenticated (0 bits)) by scandium.sabren.com (8.11.6/8.11.6) with ESMTP id gAF00Kw00950; Thu, 14 Nov 2002 19:00:21 -0500 Message-ID: <3DD438EB.2050201@apache.org> Date: Thu, 14 Nov 2002 18:59:39 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: general@incubator.apache.org CC: general@commons.apache.org, board@apache.org Subject: Re: [STATUS] (commons) Wed Nov 13 23:45:41 EST 2002 References: <200211140445.gAE4jfk11046@Boron.MeepZor.Com> <3DD3A37C.4030806@apache.org> <20021114154042.B14845@lyra.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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