Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <44b57a610805300806k5fd16fe6se18ce63b1568c459@mail.gmail.com>
Date: Fri, 30 May 2008 11:06:03 -0400
From: "Les Hazlewood" <les@hazlewood.com>
Sender: les.hazlewood@anjinllc.com
To: general@incubator.apache.org
Subject: Re: maven repository
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPAEELEOAD.noel@devtech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <f470f68e0805300556n6d8c7d76g7fc0a23c06fb619e@mail.gmail.com>
	 <NBBBJGEAGJAKLIDBKJOPAEELEOAD.noel@devtech.com>

Noel,

Could you please help me understand the fundamental reasons why this
is important to the IPMC?

I mean, I as an end-user could care less about if the dependency
artifact is in incubation or not - as long as it solves the problems
in the way the development team deems necessary, all I want to do is
just have be accessible to me immediately.  I don't care where it
comes from.  If it requires intervention on my part, I view that as a
major pain, especially if it can knowingly be avoided.  I would want
things to be as automatic and hands-off as possible.

I'm just genuinely trying to understand why the distinction is necessary.

Thanks for clarifying my naivety,

Les

On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <noel@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> it has now been clearly established that we need to move the
>> repository. we're now just asking: where?
>
> As I said, Brett Porter's proposal, made early on in the thread, seemed
> satisfactory.
>
>> asking podlings to publish through a secondary repository is both
>> annoying and ineffective at making it explicit to people that
>> they are using artifacts under incubation. this measure cuts
>> against the grain of maven.
>
> I really don't care what cuts across the grain of Maven.  I do care about
> the established principle that people must make a deliberate decision to use
> Incubator artifacts.  If Maven would finally support enforcing signing of
> artifacts, as they have been asked to do for years, we could use an
> Incubator-specific signing key, forcing people to approve the use of
> Incubator artifacts, regardless of download location.
>
> Rather than relax the principle to accomodate a defective tool, if Maven
> cannot solve this problem, I'd be more inclined to ban the use of maven
> repositories for Incubator artifacts.  That is how strongly I feel about the
> principle.
>
> By the way, there has been some talk in Infrastructure about shutting down
> the ASF's repository entirely if Maven does not provide enforcement of
> signed artifacts, due to security concerns.
>
> Look back over the years of debate on this issue, and I believe that you
> will find I've been very consistent.  I want Incubator projects to be able
> to perform releases in order to grow their (developer) community, but we
> also require that people be aware of the fact that they are not using
> official ASF code, as noted by the disclaimer.
>
>> an easy and effective way to ensure that users know that they are using
>> an artifact from the incubator would be to ensure that the group or
>> artifact ID includes this information.
>
> End users don't read the POM.  They just use it.  So that is no solution at
> all.  The signing approach would be, IMO, a reasonable solution.  It would
> solve Les' issue -- users would simply have to agree to install the
> Incubator-signed artifact(s), and thereafter they'd be fine.
>
>        --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org