Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4237FC3C.4090505@apache.org>
Date: Wed, 16 Mar 2005 10:28:28 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
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>
In-Reply-To: <81b3db074894d1f651b7d5dbcff475b6@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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?

-- 
Reinhard P�tz           Independant Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------