Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Mime-Version: 1.0 (Apple Message framework v609)
In-Reply-To: <406C52DC.6080209@gmx.de>
References: <200404011300.i31D03O26562@otsrv1.iic.ugent.be>
 <406C52DC.6080209@gmx.de>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Message-Id: <F1E75B4C-8441-11D8-8B53-000A95908E0E@wrinkledog.com>
Content-Transfer-Encoding: quoted-printable
From: Mark Lundquist <ml@wrinkledog.com>
Subject: Re: excluding unstable blocks by default (was: [WIKI-UPDATE]
 CocoonReleaseHowTo Thu Apr  1 15:00:03 2004)
Date: Thu, 1 Apr 2004 17:06:17 -0800
To: dev@cocoon.apache.org


On Apr 1, 2004, at 9:35 AM, Joerg Heinicke wrote:

> On 01.04.2004 15:00, stevenn@outerthought.org wrote:
>
>> + ! Exclude unstable blocks from the default build
>> + + Edit the blocks.properties file and exclude all unstable blocks.
>> + Since it's a release they should not get compiled by default.
>
> What about a vote on this? I'm -0.1 on excluding unstable blocks by=20
> default.

If my vote counted, I'd give -1 to default exclusion of unstable=20
blocks.  Still undecided about unstable blokes :-)

The rationale for default exclusion seems to be: "You have to ask for=20
it in order to get it, because if you asked for it then it's more=20
likely that you at least know that its status is something called=20
'unstable' (and you might even understand what that means)".  But I've=20=

yet to see a clear case for why that's so frigging important :-).  Why=20=

are unstable blocks something users need to be warned off of?  The=20
"unstable" phase is crucial for developing momentum for the coolest=20
stuff in Cocoon, and the key to that is exposure, and the key to that=20
is samples getting built by default.  Get people hooked on the cool=20
stuff when it's still unstable =97 that's what creates critical mass for=20=

getting it good enough to be stable!  (Here I'm paraphrasing, or maybe=20=

expanding :-), on a point Ugo made the other day).

There are really two "default" Cocoon configurations I'm interested in:=20=

(1) a minimal configuration, for adding things to to build my=20
production Cocoons, and (2) the full monty, Cocoon w/ all blocks and=20
samples, so that there's nothing I can't see and try out.  Default=20
inclusion/exclusion has only to do with how much work it takes me to=20
get to either of those configurations =97=A0for me it has nothing at all =
to=20
do with stable/unstable status.

What I really want is a dead dog simple way to say "build full", but=20
let "local.whatever" (I guess) take care of whatever I consider to be=20
"minimal", which is really not "minimal" at all but is rather precisely=20=

what my production needs require.

What I think I really, really want, is to be able to unpack the distro=20=

in one place but then build multiple, differently-configured cocoons=20
from the single instance of the distro.

>  And Vadim is working on th refactoring of the blocks samples page in=20=

> dependency on the stable/unstable status.

+10... maybe partition it into stable / unstable / deprecated.

My $.02...
~ml