Return-Path: 
 <dev-return-72449-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 5480 invoked from network); 16 Mar 2005 18:40:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 16 Mar 2005 18:40:05 -0000
Received: (qmail 78499 invoked by uid 500); 16 Mar 2005 18:39:51 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 78419 invoked by uid 500); 16 Mar 2005 18:39:51 -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 78362 invoked by uid 99); 16 Mar 2005 18:39:50 -0000
X-ASF-Spam-Status: No, hits=0.4 required=10.0
	tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of peter.hunsberger@gmail.com
 designates 64.233.184.206 as permitted sender)
Received: from wproxy.gmail.com (HELO wproxy.gmail.com) (64.233.184.206)
  by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 16 Mar 2005 10:39:49 -0800
Received: by wproxy.gmail.com with SMTP id 50so2973746wri
        for <dev@cocoon.apache.org>; Wed, 16 Mar 2005 10:39:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=MJys9HB55Ydu4g02KagCmJSqWzCwtFhk55m5m3TN0Opvid2lUu1a8DKF8Wp/V8KFHoF0QUoHMmNrY385q5Xlhcglt01oyTOtBrGXWRU+6dOUdXbnClHQEWDmE8HHf4IAeJ/Qo7+kcfBhEHPFR+M3M5VJacADl7eXIVKvQH+xDgw=
Received: by 10.54.32.33 with SMTP id f33mr1978761wrf;
        Wed, 16 Mar 2005 10:39:46 -0800 (PST)
Received: by 10.54.37.79 with HTTP; Wed, 16 Mar 2005 10:39:45 -0800 (PST)
Message-ID: <cc159a4a0503161039479c76a5@mail.gmail.com>
Date: Wed, 16 Mar 2005 12:39:45 -0600
From: Peter Hunsberger <peter.hunsberger@gmail.com>
Reply-To: Peter Hunsberger <peter.hunsberger@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: Supported and unsupported blocks
In-Reply-To: <42387A8B.6040203@nada.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <4236A792.2020800@apache.org> <42383B6B.70005@reverycodes.com>
	 <423841D8.1090102@nada.kth.se>
	 <53310.165.98.153.184.1110987915.squirrel@www.agssa.net>
	 <423857E3.6040506@nada.kth.se> <42385BA3.8000600@apache.org>
	 <54625.165.98.153.184.1110990271.squirrel@www.agssa.net>
	 <42386478.5030605@apache.org> <423871C3.8010009@upaya.co.uk>
	 <42387A8B.6040203@nada.kth.se>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

On Wed, 16 Mar 2005 19:27:23 +0100, Daniel Fagerstrom
<danielf@nada.kth.se> wrote:
> Upayavira wrote:
> > Reinhard Poetz wrote:

<snip/>

> > It has been said that moving directories around is likely to cause
> > confusion - where has my block gone? etc.
> 
> That's FUD, the whole lifecycle contributed->supported->deprecated is
> likely to take many years (for the few blocks that go through all
> three). And each step is a sigificant step in the blocks life and
> important for the users and is certainly not based on a sudden whim from
> the community.

Personally, I don't think that's FUD.  No matter how long it takes for
a block to make the transition form one state to another the moment if
moves directories people are not going to know where it went.

If the block build process can automatically fetch my included blocks
no matter what directory they are located in then this a lot less of a
concern. Even then, people actually working on the block will have to
realize that block X moved and not keep working on "unstable/X" since
the version used by the build is now in "stable/X".  Only moving
blocks on release boundaries would help here, but I'm not sure it
removes the problem.

So, until we have automatic block retrieval I'd vote for a flat structure.

<snip/>

> >
> > The principal argument against putting blocks into directories is that
> > we cannot know now what is the most significant designation of a block.
> 
> We certainly know: community support is by far the most significant
> designation of a block.

A stable block that has worked for years and is never in need of
maintenance might be a very valuable contribution.  Such things could
fall through the cracks if all you measure is how many people are
working on a block.

-- 
Peter Hunsberger