Return-Path: 
 <dev-return-48127-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 79176 invoked from network); 24 Sep 2003 18:41:25 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 24 Sep 2003 18:41:25 -0000
Received: (qmail 8176 invoked by uid 500); 24 Sep 2003 18:41:13 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 8006 invoked by uid 500); 24 Sep 2003 18:41:12 -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 7993 invoked from network); 24 Sep 2003 18:41:11 -0000
Received: from unknown (HELO host.leverageweb.com) (64.91.232.157)
  by daedalus.apache.org with SMTP; 24 Sep 2003 18:41:11 -0000
Received: from dhcp205169.hq.af.mil ([134.205.205.169] helo=leverageweb.com)
	by host.leverageweb.com with asmtp (Exim 3.36 #1)
	id 1A2EX3-0003bt-00
	for dev@cocoon.apache.org; Wed, 24 Sep 2003 14:38:33 -0400
Message-ID: <3F71E53B.8000802@leverageweb.com>
Date: Wed, 24 Sep 2003 14:40:59 -0400
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: on better release and version management
References: <20030924183445.68213.qmail@web41902.mail.yahoo.com>
In-Reply-To: <20030924183445.68213.qmail@web41902.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.leverageweb.com
X-AntiAbuse: Original Domain - cocoon.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - leverageweb.com
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Timothy Larson wrote:
> Maybe we are having a hard time finding the "right" word because we are
> mixing concerns.  I can think of roughly four separate things the user
> of a module would want to know:
> 
>   (1) Is the module stable?
>       (i.e. is it considered to generally work properly with no critical bugs?)
>   (2) Will code written against it will work with future releases?
>       (i.e. will there be a back-compatibility effort made in new releases?)
>   (3) Will there likely be any future versions?
>       (i.e. is there still an active development person or community?)
>   (4) Are they the only guinea pigs actually using the module?
>       (i.e. is there an active user community?)
> 
> On another tack, this information is mostly dynamic:
> 
> While case (1) is usually static, but see the planned cocoon-2.1.1 -> 2.1.2
> release for an example of this being a little dynamic.  For a stronger
> example, think of a crypto module after a security hole is found and
> fixed in a new release.  The old version transitions from stable to condemed.
> 
> Case (2) starts out as only an expression of intent and then transitions
> when a new release is made to being an attribute of the new release that
> reflects back on the release in question.
>  
> Cases (3) and (4) are not direct attributes of the module, but rather are
> attributes of the community that reflect back on the module.
> 
> In all these cases, any meta-info included in a release can only represent
> a snapshot in time.  This is useful, but it would be better if it could be
> combined with live meta-info retrieved from the module's source site upon
> download, to account for reality drift over time.
> 
> <side-note>
> Eventually it would be helpful for the source website to include the static
> meta-info, live meta-info, and some pretty, graphical data from some community
> data miners like Agora, etc. to help evaluate the liveliness of a module and
> its developer and user communities.  This could even be used by the developers
> to help track what is used, what is causing problems, what can be retired, etc.
> </side-note

What about providing this or whatever info is needed (even Stefano's 
original "strawman" proposal that he pointed out is self certifying but 
"sign" the information by an authority.  The "certification" we've been 
discussing would then really "signed" by Cocoon.  Perhaps there could be 
cobs in Cocoon's repository which are not signed, and perhaps there are 
one man shows which are "signed" because they are labeled as such.  The 
"certify"ing is done on the statement of information about the block.

Geoff