Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (herse.apache.org: domain of hedhman@gmail.com designates
 209.85.146.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:from:organization:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender;
        b=V3z/vBbdCg8o6ge/QcUpkRUjbsI2BvrQI64HitxMPJZVfZ6rH1Mb5rg/JQ/hzh1xqhx/Qjez8urWgLf7+vuenaykTdWby65mHz4REEG9T8Qpz0RFPxAp3Qd3+zGXrB0r2oq5vp+YBO2yRB8CTau+U8+9UdpItUESKhZ8c8vcDCo=
From: Niclas Hedhman <niclas@hedhman.org>
Organization: Private
To: dev@felix.apache.org
Subject: Re: [VOTE] Felix 1.0.0 subprojects release
Date: Sun, 15 Jul 2007 09:58:37 +0800
User-Agent: KMail/1.9.5
References: <487a994c0707131751m39a3dd11rfa6c9462ffeb2ac6@mail.gmail.com>
 <200707141836.47849.niclas@hedhman.org>
 <487a994c0707141656p551420bpbb60cc8fa0907bf5@mail.gmail.com>
In-Reply-To: <487a994c0707141656p551420bpbb60cc8fa0907bf5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200707150958.37450.niclas@hedhman.org>
Sender: Niclas Hedhman <hedhman@gmail.com>

On Sunday 15 July 2007 07:56, Karl Pauls wrote:
> So how do we proceed from here? I'd personally like to pause the vote
> and update the source release artifacts to include the LICENSE and
> NOTICE files in the root. Would that be a way for you to change your
> vote?

Yes, if the LICENSE and NOTICE is in root for the Source tarball, you have my 
+1.

For the Maven artifact; As I mentioned, it is still an open item on where this 
should really be. On one side is the hard liners, which basically says that 
Apache is about Open Source, and only source releases should be the ASF's 
legal responsibility. Then the pragmatic bunch (majority) thinks that 
binaries are absolutely a requirement, otherwise people won't use ASF's 
projects, and we need a legal framework (procedures, recommendations, 
archiving, ++) for binaries that is as good as the source ones. That is 
essentially agreed upon for some time already. In this context, a binary 
release refers to the produced artifacts wrapped in a tarball with 
LICENSE/NOTICE and docs.

Recently (a year or two) there are discussions on how should Maven artifacts 
be handled. Now you can start splitting the binary bunch in smaller 
undefinable camps.
There are three main issues; The license requirements, the archiving 
requirements and the 'oversight' requirements.

For long, Maven artifacts were not official, but recently there is 
a /dist/maven-repository and according to "infrastructure team" everything 
under /dist is official and archived. Not sure whether this is still true, 
since /dist/maven-repository redirects to 
http://people.apache.org/repo/m2-ibiblio-rsync-repository/, which is the 
upload area, but I think infra is now archiving this.

"Oversight" is slightly diffuse, but refers to the "many eyeballs" concept, 
and is essentially a human process. Maven makes it very easy to make 
the "release" if it wasn't for the oversight issue. And many people has 
requested Maven community to directly support the ASF manual processes in the 
release process in Maven, including call for VOTE, providing references to 
the PMC vote, and so on. That is still far away.

License requirements is mostly about the many licenses saying "prominent 
place" to refer to where the license must be. IMHO, it should be root folder 
of artifact. But I think people has objected due to the nature of Maven jars 
are active artifacts, and should not be polluted by this. META-INF is 
currently the minimum requirement, and I am still not sure whether Maven 
artifacts are official release artifacts of ASF.


I hope that is enough preaching in one go.


Cheers
Niclas