Re: Unstable stuff

[Torsten Curdt <tc...@vafer.org>]

> Well, actually my point is about user awareness. Today you just download 
> Cocoon, read the docs, type ./build.sh and see some fast-scrolling 
> messages muttering about unstable stuff, and that's it. I'm thinking of 
> something more specific that forces the user to know what she's doing. A 
> different property/target (./build.sh -Dinclude.unstable=true)? A 
> different file to edit (local.unstable.block.properties)? Everything 
> would do: but clearly a message that scrolls during the build is not 
> enough.

Well, having it disabled by default is a clear sign?

WDYT
--
Torsten

Re: Unstable stuff

[Ugo Cei <u....@cbim.it>]

Torsten Curdt wrote:
>> Well, actually my point is about user awareness. Today you just 
>> download Cocoon, read the docs, type ./build.sh and see some 
>> fast-scrolling messages muttering about unstable stuff, and that's it. 
>> I'm thinking of something more specific that forces the user to know 
>> what she's doing. A different property/target (./build.sh 
>> -Dinclude.unstable=true)? A different file to edit 
>> (local.unstable.block.properties)? Everything would do: but clearly a 
>> message that scrolls during the build is not enough.
> 
> 
> Well, having it disabled by default is a clear sign?

If we disable by default unstable blocks, first-time users won't even be 
exposed to such things as Forms, repository, OJB, portal, petstore, 
linotype, etc., which could be *huge* selling points for Cocoon, IMHO.

I'm not that worried about people being confused by two flow 
implementations, if one of them is in core and the other one is in an 
unstable block. I suspect first thing most people will do after 
downloading is running the samples. If samples for unstable blocks sport 
a large, red-lettered warning, we have nothing to fear, again IMHO.

	Ugo

Re: Unstable stuff

[Torsten Curdt <tc...@vafer.org>]

Gianugo Rabellino wrote:

> Torsten Curdt wrote:
> 
>>> Well, actually my point is about user awareness. Today you just 
>>> download Cocoon, read the docs, type ./build.sh and see some 
>>> fast-scrolling messages muttering about unstable stuff, and that's 
>>> it. I'm thinking of something more specific that forces the user to 
>>> know what she's doing. A different property/target (./build.sh 
>>> -Dinclude.unstable=true)? A different file to edit 
>>> (local.unstable.block.properties)? Everything would do: but clearly a 
>>> message that scrolls during the build is not enough.
>>
>>
>>
>> Well, having it disabled by default is a clear sign?
> 
> 
> That's not the case for a helluvalot of unstable stuff as of today...

I know  ...sorry my answer was misleading...
I like to propose to disable unstable blocks
by default.

cheers
--
Torsten

Re: Unstable stuff

[Gianugo Rabellino <gi...@apache.org>]

Torsten Curdt wrote:

>> Well, actually my point is about user awareness. Today you just 
>> download Cocoon, read the docs, type ./build.sh and see some 
>> fast-scrolling messages muttering about unstable stuff, and that's it. 
>> I'm thinking of something more specific that forces the user to know 
>> what she's doing. A different property/target (./build.sh 
>> -Dinclude.unstable=true)? A different file to edit 
>> (local.unstable.block.properties)? Everything would do: but clearly a 
>> message that scrolls during the build is not enough.
> 
> 
> Well, having it disabled by default is a clear sign?

That's not the case for a helluvalot of unstable stuff as of today...

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)