Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42380BF7.5010301@nada.kth.se>
Date: Wed, 16 Mar 2005 11:35:35 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Supported and unsupported blocks
References: <42281CF4.9050907@apache.org> <422F2607.7040907@apache.org>
 <422F2E2A.9040600@upaya.co.uk> <423018A8.3070609@apache.org>
 <42301D78.60201@nada.kth.se> <4236A792.2020800@apache.org>
 <52dc9a7562eb21a6c1b5122368bde425@apache.org>
 <20050316003824.GE17237@igg.indexgeo.com.au> <4237E1BE.70009@apache.org>
 <08be1861ca697d2419145a3c579f09f7@apache.org> <4237EE7A.1080201@apache.org>
 <81b3db074894d1f651b7d5dbcff475b6@apache.org> <4237FC3C.4090505@apache.org>
In-Reply-To: <4237FC3C.4090505@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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