incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: [policy] incubating projects and maven repositories v1.0
Date Wed, 30 Aug 2006 23:53:25 GMT
Jason,

Is it rocket science to add a new repo location in pom.xml? *Any*
maven newbie learns *very* quickly how to add a new repo. Are you
stating that *IF* the artifacts are not in the central repo they won't
find it and won't know how to use it? The least anyone will need to
know is the artifact id and version id and they find this when they
browse a project's pages, are you stating that a user will never look
at anyone's web site or download area and will *ONLY* look at ibiblio
repo and decide to use a project? If they do indeed look, isn't it
trivial to add instructions on adding info on how to add the
incubation repo? Where's the problem?

-- dims



On 8/30/06, Jason van Zyl <jason@maven.org> wrote:
>
> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>
> > On 8/30/06, Dan Diephouse <dan@envoisolutions.com> wrote:
> >> policy, so I see those as in conflict right now. So I want to know on
> >> what grounds the incubator can prevent me from requesting that some
> >> incubating jars from being uploaded to ibiblio.
> >
> > Common decency?  If we (as the project owners) ask those artifacts not
> > to be posted, then they shouldn't be posted as a matter of courtesy.
>
> It just means that we have to start watching for requests coming from
> users to put artifacts in the repository. Effectively you are asking
> us to deny the terms of redistribution stated in our license are you
> not?
>
> We could watch for requests going into Ibiblio, but we can't prevent
> someone else from putting in a repository that they might use.
>
> What is going to happen is that people are going to want to use these
> artifacts and they will want to rsync Ibiblio, which many people do,
> and then attempt to rsync  the incubator repository. We are just
> going to try and circumvent a path that we cannot fully block off.
>
> I don't see what is not clear with *every* incubator artifact being
> marked with a version that has "incubator" in it. Plus the reports
> that can be generated give a clear view to users what they are
> consuming.
>
> I read this:
>
> http://marc.theaimsgroup.com/?l=incubator-general&m=115440663222532&w=2
>
> and to be frank (4) is somewhat paradoxical to me. You want an
> incubator project to thrive, and grow while we are tacitly, yet
> actively, discouraging their use? I think we should let people use
> their common sense to protect themselves.
>
> What is being envisioned here as the worst case scenario of using an
> incubator artifact for a failed incubator project? The mail says
> protect the user, but from what?
>
> I'm not going to discourage the use of a project I'm mentoring and
> fully support. I'm going to get everyone on the planet I can to use
> it as fast and as widely as possible.
>
> > -- justin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> Jason van Zyl
> jason@maven.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

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


Mime
View raw message