Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <406D425B.9040904@upaya.co.uk>
Date: Fri, 02 Apr 2004 11:37:15 +0100
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: excluding unstable blocks by default
References: <200404011300.i31D03O26562@otsrv1.iic.ugent.be>
 <406C52DC.6080209@gmx.de>
 <F1E75B4C-8441-11D8-8B53-000A95908E0E@wrinkledog.com>
In-Reply-To: <F1E75B4C-8441-11D8-8B53-000A95908E0E@wrinkledog.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

To my mind, Mark makes some interesting points here. Could we get away 
from using a simple include/exclude, and have:

build stable      <-- only stable stuff
build unstable   <-- stable and unstable
build webapp   <-- only stable stuff

Or better:

configure stable      <-- only stable stuff
configure unstable   <-- stable and unstable
configure webapp   <-- only stable stuff

That way, it isn't much work to get the unstable stuff, but you've got 
to ask for it.

Upayavira,  who's busilly trying to catch up with cocoon-dev.

Mark Lundquist wrote:

>
> 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 
>> default.
>
>
> If my vote counted, I'd give -1 to default exclusion of unstable 
> blocks.  Still undecided about unstable blokes :-)
>
> The rationale for default exclusion seems to be: "You have to ask for 
> it in order to get it, because if you asked for it then it's more 
> likely that you at least know that its status is something called 
> 'unstable' (and you might even understand what that means)".  But I've 
> yet to see a clear case for why that's so frigging important :-).  Why 
> are unstable blocks something users need to be warned off of?  The 
> "unstable" phase is crucial for developing momentum for the coolest 
> stuff in Cocoon, and the key to that is exposure, and the key to that 
> is samples getting built by default.  Get people hooked on the cool 
> stuff when it's still unstable � that's what creates critical mass for 
> getting it good enough to be stable!  (Here I'm paraphrasing, or maybe 
> expanding :-), on a point Ugo made the other day).
>
> There are really two "default" Cocoon configurations I'm interested 
> in: (1) a minimal configuration, for adding things to to build my 
> production Cocoons, and (2) the full monty, Cocoon w/ all blocks and 
> samples, so that there's nothing I can't see and try out.  Default 
> inclusion/exclusion has only to do with how much work it takes me to 
> get to either of those configurations � for me it has nothing at all 
> to do with stable/unstable status.
>
> What I really want is a dead dog simple way to say "build full", but 
> let "local.whatever" (I guess) take care of whatever I consider to be 
> "minimal", which is really not "minimal" at all but is rather 
> precisely what my production needs require.
>
> What I think I really, really want, is to be able to unpack the distro 
> in one place but then build multiple, differently-configured cocoons 
> from the single instance of the distro.
>
>>  And Vadim is working on th refactoring of the blocks samples page in 
>> dependency on the stable/unstable status.
>
>
> +10... maybe partition it into stable / unstable / deprecated.
>
> My $.02...
> ~ml
>
>