Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of hedhman@gmail.com designates
 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
        b=aXZsSV537Ze+oV7+jRYmpvH5IDjKg/AC2nHStUF416u6i3IBT4gHLQ9c5tZnZYKzUPQaMlSYzNiLwEDJnwvcMY/JWGoY3oePA5M8KunMUKRmEQvnBFa/MLlkjbWdodhGavF1owKUBnLG58q9qE6z91uwHEKAxCAFLrXelo6qBd8=
From: Niclas Hedhman <niclas@hedhman.org>
To: dev@cocoon.apache.org
Subject: Re: Automatic releases
Date: Fri, 26 May 2006 18:51:39 +0800
User-Agent: KMail/1.8.3
References: <44748DE5.50402@apache.org> <e52c3n$nd1$1@sea.gmane.org>
 <4474BCB2.6070809@apache.org>
In-Reply-To: <4474BCB2.6070809@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200605261851.39399.niclas@hedhman.org>
Sender: Niclas Hedhman <hedhman@gmail.com>

On Thursday 25 May 2006 04:06, Reinhard Poetz wrote:
> But basically you're right that we have to clarify the situation in
> general. How shall we proceed to get an answer to the question of
> "unofficial" artifact releases? Is the pmc@cocoon in the position to decide
> such things itself our do we have to discuss this issue with board@apache?
> WDOT?

"Automatic releases" are not a possibility, for two main reasons;

 1. Resources ; Someone pointed out how many artifacts would be created (and 
in fact Maven will generate a bunch more, such 
as .pom, .sha1, .md5, .pom.md5, .pom.sha1. Someone else suggested that these 
would only exist until the next release. That is also not an option. Maven 
relies on the fact that any build will work 'forever', as old artifacts does 
not disappear.


 2. Legal ; ALL releases from ASF MUST be under the oversight of the 
responsible PMC. That means active insight and control of what is put into 
the release, and vouching legally that this is a non-malicious artifact 
suitable for consumption under a set of constraints. "Automatic releases" 
bypasses such legal responsibility, and will be found unacceptable by the 
Board and legal counsel.


The obvious solution to the "problem" is smaller components with independent 
release cycles, but we know that since *years*...


Cheers
Niclas