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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
