Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 62511 invoked from network); 27 Mar 2002 00:52:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Mar 2002 00:52:53 -0000 Received: (qmail 25138 invoked by uid 97); 27 Mar 2002 00:52:59 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 25106 invoked by uid 97); 27 Mar 2002 00:52:58 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 25095 invoked from network); 27 Mar 2002 00:52:58 -0000 Message-ID: <20020327005258.45587.qmail@web12702.mail.yahoo.com> Date: Tue, 26 Mar 2002 16:52:58 -0800 (PST) From: Otis Gospodnetic Subject: Re: Action Item Vote Request To: Lucene Developers List In-Reply-To: <1017187444.11829.1855.camel@linux2.superlinksoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Brian, > > > I prefer instead to have the /contrib area a separate CVS repo. > My > > > experience in other OS projects is that (a) contrib areas rapidly > get > > > to be larger than then main distribution, making downloads > slower, and > > > (b) often get out of sync with the main distribution. The result > is > > > that a mix of core code and contributions of varying levels of > > > quality, completedness, and maintainedness tends to lower the > perceived > > > level of quality of the distribution. > > > > > > So +1 for a /contrib area, -1 for making it part of the main CVS > repo > > > and distribution. Even if the contents of /contrib are compressed archives (e.g. .zip or .tgz or ...)? That way the sync question is not a problem - we just provide the packages, we do not try to repackage them. Also, they would not be a part of the distribution that users get, would they Peter? They would be available separately, somehow (perhaps via links from the Contributions page pointing straight to the CVS repository's /contrib section). With that in mind, again if I'm not misinterpreting things, would you still vote against it? > > >> 2) Create a scratchpad area in the Lucene CVS > > >> (org.apache.lucene.scratchpad). This area would be focused on > creating new > > >> parts of the Lucene core in an experimental mode. This code > would be > > >> considered unstable and unsupported. If a part becomes stable > and is desired > > >> to be moved into the Lucene core build, it must be approved > through a > > >> committers vote (+3 votes). > > > > > > Again, -1 if this is part of the main CVS repo, +1 on the > concept. It sounds like you are saying the arguments for this -1 are the same as for the above (size and sync issue). My understanding is that stuff in scratchpad would not really be trying to remain in sync with outside code. Isn't that so, Andrew? And as for size, this would not be a pile of code, plus it would not be in the Lucene distribution, so you would only see it if you are updating your CVS repository. No? Do you still give this -1? If so, could you please provide some alternative ideas? Thanks, Otis __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/ -- To unsubscribe, e-mail: For additional commands, e-mail: