incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: [DISCUSS] Do we really need an incubator?
Date Tue, 08 Jul 2008 00:41:27 GMT

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?


On Mon, Jul 7, 2008 at 8:06 PM, Roy T. Fielding <> 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:
> For additional commands, e-mail:

Davanum Srinivas ::

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message