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 jhaile@fastmail.fm designates
 66.111.4.25 as permitted sender)
Message-Id: <1C96CB2D-0768-4E3B-8346-C6FF26BBB0FA@fastmail.fm>
From: Jeremy Haile <jhaile@fastmail.fm>
To: general@incubator.apache.org
In-Reply-To: <44b57a610805300843t32db4cf5te04e2537bf72fc87@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: maven repository
Date: Fri, 30 May 2008 12:15:37 -0400
References: <f470f68e0805300556n6d8c7d76g7fc0a23c06fb619e@mail.gmail.com>
 <NBBBJGEAGJAKLIDBKJOPAEELEOAD.noel@devtech.com>
 <44b57a610805300806k5fd16fe6se18ce63b1568c459@mail.gmail.com>
 <f2e8eedf0805300814q5c7982e0h5e6b5d32c82989be@mail.gmail.com>
 <ECC85F97-B34F-4009-B286-10B3D991DDC5@fastmail.fm>
 <f2e8eedf0805300838u5104381awa6518865fbda43a6@mail.gmail.com>
 <44b57a610805300843t32db4cf5te04e2537bf72fc87@mail.gmail.com>

Yeah - coming from the point of view of a project working on entering  
the incubator, I'd rather have tough IP restrictions on entering the  
incubator, but once I'm in the incubator have an environment that most  
effectively promotes growth and adoption of the project.  Rather than  
feeling like we are taking a step backwards in adoption by joining the  
incubator.

Currently JSecurity has a community, is published to Maven, and does  
regular releases.  If joining the incubator meant that we were no  
longer approved to do releases to our community, that seems like a  
hindrance to adoption.  If people can no longer download releases via  
Maven without going through annoying steps that make it seem immature  
and unreliable, then that's a hindrance to adoption.

I'd much rather have a strict process up front that get it IP  
clearance and then make it easy for people to adopt, than to enter the  
incubation process and have hindrances put in place.

Perhaps one idea is to not treat all projects or incubation proposals  
the same.  Some projects could choose to enter the incubator now, have  
access to Apache's infrastructure, etc. and gain IP clearance at some  
later date where they can then do releases.  Other more established  
projects could choose to front-load the IP clearance and have that  
occur before they are even accepted.  In those cases, once they are  
accepted, they can immediately continue to do releases and foster the  
community growth.

Just throwing out my 2 cents...

On May 30, 2008, at 11:43 AM, Les Hazlewood wrote:

> Hrm - I thought you had to have IP clearance before you even were
> accepted as a podling.  Or maybe its just that Alan is such a great
> Champion for us, that he helped us along that path before we even
> submitted our proposal ;)
>
> Under this assumption (that IP clearance exists already), it makes
> much more sense to allow the podling to publish approved releases to
> the central repository, but still under an
> org.apache.incubator.projectname group id to maintain
> convention/simplicity.
>
> On Fri, May 30, 2008 at 11:38 AM, James Carman
> <james@carmanconsulting.com> wrote:
>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jhaile@fastmail.fm>  
>> wrote:
>>> So it seems that a valid question is whether or not publishing to  
>>> one
>>> repository or another indicates an endorsement.
>>
>> Yes, that's certainly a valid question.  Again, that's just my
>> personal point of view.
>>
>> The biggest problem with incubator projects (again my opinion) having
>> releases is the IP clearance.  Perhaps there should be multiple  
>> stages
>> of incubation.  The first stage should be where you verify the IP
>> clearance and projects in that stage shouldn't be allowed to do
>> releases at all.  Then they might graduate to the next stage and that
>> would be a "community building" stage where we make sure the project
>> has enough community around it.  These projects should be able to
>> provide incubating releases.
>>
>> ---------------------------------------------------------------------
>> 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
>


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