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: <44b57a610805301044g7acbd306nc1f49a7ee269ab0a@mail.gmail.com>
Date: Fri, 30 May 2008 13:44:53 -0400
From: "Les Hazlewood" <les@hazlewood.com>
Sender: les.hazlewood@anjinllc.com
To: general@incubator.apache.org
Subject: Re: maven repository
In-Reply-To: <25aac9fc0805301024v5bcf40eere590818c8748ad5b@mail.gmail.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>
	 <44b57a610805300806k5fd16fe6se18ce63b1568c459@mail.gmail.com>
	 <f2e8eedf0805300814q5c7982e0h5e6b5d32c82989be@mail.gmail.com>
	 <ECC85F97-B34F-4009-B286-10B3D991DDC5@fastmail.fm>
	 <f2e8eedf0805300838u5104381awa6518865fbda43a6@mail.gmail.com>
	 <44b57a610805300843t32db4cf5te04e2537bf72fc87@mail.gmail.com>
	 <f2e8eedf0805300916y329768eckd36d6c6f5e14ebf2@mail.gmail.com>
	 <44b57a610805300927o7ef88513yd860a1e9a102f3b8@mail.gmail.com>
	 <25aac9fc0805301024v5bcf40eere590818c8748ad5b@mail.gmail.com>

I think that that the term "Incubator" is well understood.  Almost
everyone in the software world understands that term.  For the very
few that might not, a quick dictionary or google search, or a visit to
incubator.apache.org would make that very clear.  That's good enough.
Unless there is an absolute legal obligation to actually force the
end-user to recognize that dependency, it is just adding noise.  Keep
It Super Simple.

> Also, then a non-incubator project uses the incubator project as a dependency.
> This hides the incubator dependency - no thank you!

There is nothing wrong with a non-incubator project using the
incubator project as a dependency, as long as the incubator project IP
has been cleared.  See Daniel Kulp's latest response in the parallel
thread related to this topic for why there are many good reasons why
incubator projects can or should be used in non-incubator projects.

A dependency on an incubator's artifact is a decision by the project's
PMC and should remain so  - they know their project better than anyone
and would know best to include that dependency or not.  End users of
that project rarely if ever care if a incubator dependency exists.

So if my two proposed conditions are met (IP clearance as a
stipulation), then I feel with comfortable certainty that no one will
care.

If you want to make it known that a project has transitive
dependencies, it would be far better to note that in the project's
README file.  Plus naming the maven group id with 'incubator' in it.
Plus the Apache 2.0 license part that states "software distributed
under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND".  That is more than enough due
diligence.  Developers don't want to be bothered by this stuff, and if
they do, its clearly documented and the CYA notion is covered.

On Fri, May 30, 2008 at 1:24 PM, sebb <sebbaz@gmail.com> wrote:
> On 30/05/2008, Les Hazlewood <les@hazlewood.com> wrote:
>> My proposed solution:
>>
>>  1.  A podling could not issue a release until after IP issues have
>>  been cleared by the IPMC.
>>  2.  Once a podling's release has been approved (which includes IP
>>  approval), they would release to the central maven repository under
>>  the group id org.apache.incubator.podlingname, enabling easy adoption
>>  by end users.
>>
>>  Having the word 'incubator' in the group id conforms to repo
>>  conventions matching domain names thereby not surprising any
>>  end-users, and also explicitly requires the developer editing the pom
>>  or ivy config to visually recognize it is _not_ an ASF TLP.  Because
>>  they explicitly manually include the word 'incubator', they know its
>>  not an official ASF endorsed project.
>
> Assuming that the meaning of "Incubator" is well understood - which
> may not be the case.
>
> Also, then a non-incubator project uses the incubator project as a dependency.
> This hides the incubator dependency - no thank you!
>
>>  On Fri, May 30, 2008 at 12:16 PM, James Carman
>>
>> <james@carmanconsulting.com> wrote:
>>  > So, let's define the goals here:
>>  >
>>  > 1.  The ASF would like folks who want to use incubating projects to do
>>  > so knowingly somehow.  This is somewhat of a CYA tactic so that people
>>  > are acknowledging "yes, I understand this is not an 'official' ASF
>>  > project, but I'd like to use it anyway."
>>  > 2.  Incubating projects would like to be able to get releases in front
>>  > of people so that they can build their community.
>>  >
>>  >
>>  >
>>  > On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <les@hazlewood.com> 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
>>  >
>>  >
>>
>>  ---------------------------------------------------------------------
>>  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