Return-Path: 
 <dev-return-72437-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 89617 invoked from network); 16 Mar 2005 16:07:45 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 16 Mar 2005 16:07:44 -0000
Received: (qmail 32153 invoked by uid 500); 16 Mar 2005 16:07:42 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 32065 invoked by uid 500); 16 Mar 2005 16:07:41 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 32052 invoked by uid 99); 16 Mar 2005 16:07:41 -0000
X-ASF-Spam-Status: No, hits=0.1 required=10.0
	tests=FORGED_RCVD_HELO
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from agssa.net (HELO ags01.agsoftware.dnsalias.com) (165.98.153.184)
  by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 16 Mar 2005 08:07:41 -0800
Received: from ags01.agsoftware.dnsalias.com (localhost.localdomain
 [127.0.0.1])
	by ags01.agsoftware.dnsalias.com (8.12.11/8.12.11) with ESMTP id
 j2GG7c3Y028124
	for <dev@cocoon.apache.org>; Wed, 16 Mar 2005 10:07:38 -0600
Received: (from apache@localhost)
	by ags01.agsoftware.dnsalias.com (8.12.11/8.12.11/Submit) id j2GG7cnE028123;
	Wed, 16 Mar 2005 10:07:38 -0600
X-Authentication-Warning: ags01.agsoftware.dnsalias.com: apache set sender to
 agallardo@agssa.net using -f
Received: from 165.98.153.184 (proxying for 10.0.0.50)
        (SquirrelMail authenticated user agallardo);
        by www.agssa.net with HTTP;
        Wed, 16 Mar 2005 10:07:38 -0600 (CST)
Message-ID: <54204.165.98.153.184.1110989258.squirrel@www.agssa.net>
In-Reply-To: <423857E3.6040506@nada.kth.se>
References: <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> <423824B9.5020801@reverycodes.com>   
    <423825BF.4090109@apache.org> <20050316134610.GC23086@localhost>   
    <42383B6B.70005@reverycodes.com> <423841D8.1090102@nada.kth.se>
    <53310.165.98.153.184.1110987915.squirrel@www.agssa.net>
    <423857E3.6040506@nada.kth.se>
Date: Wed, 16 Mar 2005 10:07:38 -0600 (CST)
Subject: Re: Supported and unsupported blocks
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-6.FC2
X-Mailer: SquirrelMail/1.4.3a-6.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

On Mie, 16 de Marzo de 2005, 9:59, Daniel Fagerstrom dijo:
> Antonio Gallardo wrote:
>
>>On Mie, 16 de Marzo de 2005, 8:25, Daniel Fagerstrom dijo:
>>
>>
> <snip/>
>
>>>Am I and Reinhard the only ones that are concerned about what the 50+
>>>blocks in an unordered lump in Cocoon does for the perception about our
>>>project?
>>>
>>>
>>
>>Well, I need to say I am not concerned. Playing with the directory
>>structure is not good. I can see in the future people mails:
>>
>>                             - O -
>>
>>mail: "I canot find the block 'X' in the 'supported' dir as is stated in
>>the mail 'Y'.
>>reply: "No it was noved to contributted lat week on the SVN"
>>re:reply: "It will be on the "resurected" block the next week
>>
>>
> You are exagerating quite a bit ;)

Yep. I know. But the mails will be there.

> The proposed life cycle of block is rather:
>
> * You get a cool new idea and create a contributed block.
> * After a while it might have happened that a number of other developers
> also have become interested in the block and have started to contribute.
> At this point someone starts a vote about that the block should become a
> supported block, and people agree.
> * After some years it might happen that new technology or something else
> makes the block less relevant and someone start a vote about deprecating
> it.

The lifecycle was agreed for the community, the point is if a directory
structure is the best to implement it. Other people (me included) think it
can be implemented using the metadata file that all in all every block
will have.

Best Regards,

Antonio Gallardo