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] > > -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
