From jackrabbit-dev-return-371-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Thu Nov 18 16:44:48 2004
Return-Path:
Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org
Received: (qmail 75181 invoked from network); 18 Nov 2004 16:44:48 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur-2.apache.org with SMTP; 18 Nov 2004 16:44:48 -0000
Received: (qmail 69629 invoked by uid 500); 18 Nov 2004 16:44:44 -0000
Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: jackrabbit-dev@incubator.apache.org
Delivered-To: mailing list jackrabbit-dev@incubator.apache.org
Received: (qmail 69544 invoked by uid 99); 18 Nov 2004 16:44:43 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from [62.140.213.123] (HELO pulse.betaversion.org) (62.140.213.123)
by apache.org (qpsmtpd/0.28) with SMTP; Thu, 18 Nov 2004 08:44:40 -0800
Received: (qmail 4866 invoked from network); 18 Nov 2004 16:44:33 -0000
Received: from unknown (HELO ?127.0.0.1?) (stefano@127.0.0.1)
by pulse.betaversion.org with SMTP; 18 Nov 2004 16:44:33 -0000
Message-ID: <419CD177.2060103@apache.org>
Date: Thu, 18 Nov 2004 08:44:39 -0800
From: Stefano Mazzocchi
Organization: Apache Software Foundation
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Sandboxing
References: <018301c4c95f$fba42050$6601000a@MYAGENT102>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N
David Nuescheler wrote:
> another question that i have for the entire
> jackrabbit-dev-community:
> since it seems like a number of people started to
> implement jackrabbit pms and other
> extensions that maybe are not finished, should we
> create a section of the svn tree dedicated to
> experimental code in general? some sort of sandbox
> or proposals. experiences from other projects?
one thing I strongly advise against, is the creation of "personal
branches", these tend to increase the chance of "code ownership" which
normally leads to friction in the community.
There are two ways of doing this:
1) internal work area
2) external work area
as an example, cocoon uses both (the first is called "scratchpad" the
second is called "whiteboard"). The scratchpad is for little modules
that hook into the same core, the whiteboard is for proposals that
change the core.
None of these are "branches" because they are not guaranteed to make it
into the trunk at any point in time, you can think of it as a mini
incubator. Other projects call it "sandbox" (jakarta-commons, for example).
Personally, I would suggest to try to force everybody to work on the
same tree at any given moment in time. If that is not possible, the
internal work area should be preferred.
The reason for the above is that community building is done by making
people talk and the more isolation the less people will have to confront
until it's too late and incompatible decisions were made or lots of
efforts were spent in development that the community might decide not o
use (and this pisses people off, normally).
So, work incrementally, small patches and small discussions, one step at
a time. As thermodynamics teaches, entropy is not increased with
reversible steps. Try to make every step reversible, so that noise and
disorder does not increase.
If that is not possible, try hard to minimize the impact and keep the
communication channels open, even if, and especially, if this means
making the life harder for the developers. Most of them believe that
"continuous integration" is a waste of time and that "incremental
reversible development" is uselessly harder.
They all change their mind sooner of later ;-)
--
Stefano.