Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of cctrieloff@redhat.com
 designates 66.187.233.31 as permitted sender)
Message-ID: <4872BB7C.8070904@redhat.com>
Date: Mon, 07 Jul 2008 20:57:32 -0400
From: Carl Trieloff <cctrieloff@redhat.com>
Reply-To: cctrieloff@redhat.com
Organization: Red Hat
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Do we really need an incubator?
References: <19e0530f0807071409t310c9d4bn99d7ba368acc1d60@mail.gmail.com>
	 <B4E8BB26-7553-4E5A-BDD3-F2051EFE0F56@apache.org>
	 <19e0530f0807071559v55baf27dvcc21d3a66ecc466b@mail.gmail.com>
	 <FBFCAB70-4B76-4757-9DA9-3F30F8D28BD0@gbiv.com>
 <19e0530f0807071741i51c3a9a3o3d3e43e5edcb151d@mail.gmail.com>
In-Reply-To: <19e0530f0807071741i51c3a9a3o3d3e43e5edcb151d@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050506000009050701080309"

--------------050506000009050701080309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


 From what I have seen many of the incubator releases have been better 
vetted than those
from graduated projects. So I don't buy the argument.

I also had to bite my tough on the maven thread.. I think it is mostly 
BS to give Java an easy
route to publicity from inside incubator if no other coding language 
gets the same perks. So
to be consistent, we might as well throw it all open. At that point the 
motivation to graduate
is mostly removed. i.e. are we turning incubator into - did the project 
stay active to n months and
is the IP clear? That would be what we are practically doing.

I would personally vote -1 on the maven thread until Dims questions and 
the role of incubator
in the new world is defined.

Carl.


Davanum Srinivas wrote:
> Roy,
>
> I see what you are saying...
>
> Do you agree that the intention is for the end user to pause for a
> second to understand what he/she is using and understand that there
> are some disclaimers etc that go along with a set of artifacts?
>
> Yes. may be this is the wrong way to enforce that intention. But may
> be the clever minds on the list can come up with brilliant ideas/patch
> to maven to make this happen in a better way? then we would not have
> this issue at all. Right?
>
> Yes, we are 100% behind our released artifacts. But we do need to let
> folks know that next month the code may not have a community behind it
> and hence a liability on the users since not all our projects pass
> incubation. No?
>
> thanks,
> dims
>
> On Mon, Jul 7, 2008 at 8:06 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>   
>> Dims, I have to disagree.  The releases that we allow incubating projects
>> to make, with three +1s and a majority approval, are full Apache releases.
>> They have been officially approved by the foundation and we are 100%
>> responsible for their content. That's okay, because they also tend to
>> receive far more detailed inspection and thus are better quality and more
>> conforming to our policies then our pre-incubator TLPs.
>>
>> There is no reason for a separate repository.  It certainly isn't relevant
>> to a podling's desire to become a TLP -- that is more than adequately
>> compensated by the freedom from slow IPMC approvals and ability to host
>> their own website without the butt-ugly egg icon and disclaimers.  A
>> separate repo does not help protect "users" from incubator code, since
>> users don't set the Maven configs that define which repos to use and
>> which modules are dependencies.  At best, what it does is add an
>> irrelevant incubator layer on top of all Maven repo requests that masks
>> the "normal" repo path from developers, introduces another way to inject
>> insecure code, and wastes our bandwidth sending 404 responses to
>> automated build requests.
>>
>> In contrast, if real incubator releases are allowed to be placed in the
>> normal Maven locations, then the incubating config does not mask the
>> normal Maven path, there is no need to send *all* repo requests to
>> incubator first, the project documentation for Maven doesn't have to
>> be a special-case, and releases are still subject to the same quality
>> controls as all Apache releases.
>>
>> Regardless, the user never makes a decision regarding incubator code
>> in the Maven repo.  The user is either going to pull the incubator
>> release directly and then build it using Maven with the provided pom,
>> or some other project is going to make a decision to add the artifact
>> (with incubator in its name) as a dependency.  The Maven repo path is
>> irrelevant to the user's decisions -- it just changes the background
>> bit traffic and the load on our servers.  In short, the policy is
>> just plain stupid (speaking as a C developer who builds a few
>> projects via Maven only a couple times a year).
>>
>> Yes, it would be nice if Maven was more secure, properly checked
>> signatures, and properly delegated namespaces so that third-parties
>> would be unable to add artifacts within other org's trees.  None of
>> those issues are specific to incubator.
>>
>> ....Roy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>>     
>
>
>
>   


--------------050506000009050701080309--