Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 63841 invoked from network); 5 Feb 2003 23:00:52 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 5 Feb 2003 23:00:52 -0000 Received: (qmail 27959 invoked by uid 97); 5 Feb 2003 23:02:25 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@nagoya.betaversion.org Received: (qmail 27952 invoked from network); 5 Feb 2003 23:02:25 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 5 Feb 2003 23:02:25 -0000 Received: (qmail 63206 invoked by uid 500); 5 Feb 2003 23:00:46 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 63030 invoked from network); 5 Feb 2003 23:00:44 -0000 Received: from lsne-catv-dhcp-43-155.urbanet.ch (HELO mail.qos.ch) (80.238.43.155) by daedalus.apache.org with SMTP; 5 Feb 2003 23:00:44 -0000 Received: from eitan.qos.ch (eitan [192.168.1.4]) by mail.qos.ch (Postfix) with ESMTP id 6610C15E40A for ; Thu, 6 Feb 2003 00:25:49 +0100 (CET) Message-Id: <5.2.0.9.0.20030205232643.01b3e0d0@mail.qos.ch> X-Sender: ceki@mail.qos.ch (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 06 Feb 2003 00:00:52 +0100 To: "Log4J Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: RE: moving filters to log4j-sandbox In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 10:32 05.02.2003 -0800, you wrote: >The only developers that will go to the trouble will be those enthusiastic >enough to make a contribution, the ones that need the feedback from the >general user community. No normal user will go to the trouble. I may be >wrong, but that is my belief. Making it *very* easy for users will not necessarily result in more feedback. Users look at the code in order to resolve a bug or an issue they might have. They act on necessity. If a sandbox component fulfills a need they have, they will come forward with comments. The goal of the sandbox is to allow more developers to create freely. Shortening the release cycle is a different goal. Stefano Mazzocchi (Cocoon, Avalon, etc.) often quips that the easiest way to get users working on your code, is to have it do something useful but with bugs inside. Developers will scramble to fix them and learn your code in the process. > > Yes, we can be lax as long as the contents of the sandbox are > > *not* for > > release. If the sandbox is just a log4j supplement, then it > > will demand the > > same maintenance costs as log4j itself. > >I guess I don't understand why this must be the case. Is there some jakarta >apache bylaw that is in effect here? The rationale for forbidding commons-sandbox releases stems from the openness of the sandbox. Since any committer can start a project within the sandbox simply by asking, commons committes exert some control by disallowing releases. I believe this was a demand from the PMC or the Board but I am unsure. >-Mark -- Ceki --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: log4j-dev-help@jakarta.apache.org