Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Received-SPF: pass (herse.apache.org: domain of flamefew@gmail.com designates
 64.233.184.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FckXF1gpLuNFmd3Xg1F2Xo0GL9zAfRxxjbP0jVjIkoupcjKTOqT1E1W9wEWXYwzSyGxQtCLXkiDWsuRYX6B8EclUChS2rq+kZfS1xjKhd86Zij/0MImmz8WdXMq8tjC25sCVVrxFQ0r7397coVqsLDcPJxtEuWBLMhxeyTkoaZ8=
Message-ID: <31cc37360612121345k1010a06crdb08ea83377a582b@mail.gmail.com>
Date: Tue, 12 Dec 2006 13:45:45 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: repository@apache.org
Subject: Re: [repo] /www/people.apache.org/repo/m1-ibiblio-rsync-repository/
Cc: dims@apache.org
In-Reply-To: <c84a50780612121330u52b6e864wf51b87591c1a944b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061211091504.18111.qmail@minotaur.apache.org>
	 <adba96190612112148n246b0246tb8050279de2ac933@mail.gmail.com>
	 <9d4ec10b0612112204l3bc9fa3fh138ea2bcc1c9e2b4@mail.gmail.com>
	 <1a5b6c410612120232x22eff7a0te31c712d0e87f8fe@mail.gmail.com>
	 <19e0530f0612120601k3c8da1dbodfede2702491a8e4@mail.gmail.com>
	 <1a5b6c410612121211y16ddbcf8mbde0df0346041192@mail.gmail.com>
	 <19e0530f0612121235s2302789cl264cbc5dbafaf657@mail.gmail.com>
	 <1a5b6c410612121254x21d4bafcw69f3beebf7878e18@mail.gmail.com>
	 <19e0530f0612121306i3a1ccacbq31020d8924e703d@mail.gmail.com>
	 <c84a50780612121330u52b6e864wf51b87591c1a944b@mail.gmail.com>

On 12/12/06, Steve Loughran <steve.loughran@gmail.com> wrote:
> (replying to all as I dont yet know if dims is on repository@)
>
> On 12/12/06, Davanum Srinivas <davanum@gmail.com> wrote:
> > Don't worry carlos. Let's set up a process. Let's document what we
> > process we want everyone to conform to on our Wiki then inform infra
> > folks. Let them look it over and then we can set a date for new
> > releases to conform to the policy. Does that sound like a plan?
> >
>
> 1. Nobody releases artifacts that arent signed off by the relevant PMC.

+1

That's a current rule - enforcement being the key.

> 2. No artifacts get released if their explicit/implicit metadata is invalid

+1

That's a current rule (?) enforcement being the key.

>   -POMs have schema declaration and are valid against the schema
>   -POMs have no unexpanded ${project.version} values
>   -all dependencies resolve. You cannot depend on sun stuff that
> doesnt at least have a stub.
>   -dependency graph is acyclic and no ambiguities (conflicting
> artifacts at the same depth)
>   -until we have an automated solution, all artifacts will be held in
> staging until hand audited. That means scanning the artifact looking
> for common-troublespots (testing artifacts non-optional, etc)
>   -checksums exist and are correct.
>   -MD includes license and POM author info.
>
> In an ideal world we'd audit the JARs and look for trouble there too.
>  -Java1.5+ class files (warn, dont reject :)

Yeah, as highly likely this could be intentional.

>  -copied in class files from other JARs
> I dont have any stats on how much of an issue this is, yet.
>
> As far as I'm concerned, the repository team is not over-strict;
> they've been far too forgiving of the stuff that goes in there,
> accepting artifacts in the wrong place and with truly awful metadata.
> Nobody benefits from that.

Others:

GPG signing on all artifacts.
Javadoc/Source for all artifacts?
Does this apply to the m1 repository?
Do we clean the current m2 repository?
Does it apply to snapshot repositories?

Hen