cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Supported and unsupported blocks
Date Wed, 16 Mar 2005 10:35:35 GMT
Reinhard Poetz wrote:

> Bertrand Delacretaz wrote:
>
>> Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :
>>
>>> ...Remains the question: What shall we do with and call 
>>> "unsupported/unverified" blocks?...
>>
>>
>>
>> Why not put them in a "contributed" area? We'd make no guarantees 
>> about them (not even that they compile), and over time they might 
>> move elsewhere or be abandoned. More or less like the scratchpad of 
>> today.
>>
>> The initial move would be to put as many blocks there as possible, 
>> and maybe move them back to "higher ground" later if there is actual 
>> support for them in the community.
>
>
> My second search was more successful and I found 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2 
> which already contains an excellent proposal by Stefano:
>
>               +------------------(rebirth)-----------------+
>               v                                            |
> -(birth)-> [contributed] ----------(death)---------> [deprecated]
>               |                                            ^
>               +--(maturity)-> [supported] --(retirement)---+
>
>
>
> So we have following lifecycle states:
>
>  - contributed
>  - supported
>  - deprecated
>
> blocks.
>
> The "verified" status could be orthogonal to these lifecycle-states 
> and is an indicator of a (to be definded) block's quality (tested, 
> stable interfaces, stable implementation, supported by community, ...)
>
>
> Addtionally I like Betrands idea 
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) 
> of a narrative status description:
>
> "Yes - and maybe we shouldn't impose too much structure on this weather
> report, just require that block providers have one "block status"
> documentation page, where they tell people about contract stability,
> API stability, future plans, active contributors and the like."
>
> I think we should provide some structure by providing a template that 
> has some mandatory parts and a free text part.
>
>                              - o -
>
> I propose to reflect these lifecycle-states in our SVN directory 
> structure. Additionally we should add the directories "samples" and 
> "core".
>
> /cocoon/blocks/contributed
> /cocoon/blocks/supported
> /cocoon/blocks/deprecated
> /cocoon/blocks/core
> /cocoon/blocks/samples
>
> Remains the question, where do "mini-apps" like the querybean fit in? 
> In contrary to sample-blocks they have a lifecycle IMO. I'm not sure 
> whether a distinction between "functional blocks" and "mini-apps" on 
> SVN directory level really makes sense. For now I propose to put 
> mini-apps into "contributed", "supported" or "deprecated" and if we 
> get swamped with "mini-apps" we can find another solution if it is 
> necessary.
>
> WDOT?
>
+1

I agree about all of it. Contributed is more to the point than 
unsupported and doesn't have the negative conotation.

/Daniel


Mime
View raw message