cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist>
Subject Re: excluding unstable blocks by default (was: [WIKI-UPDATE] CocoonReleaseHowTo Thu Apr 1 15:00:03 2004)
Date Fri, 02 Apr 2004 01:06:17 GMT

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

> On 01.04.2004 15:00, wrote:
>> + ! Exclude unstable blocks from the default build
>> + + Edit the 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...

View raw message