| From | Sent On | Attachments |
|---|---|---|
| Davanum Srinivas | Jul 7, 2008 2:08 pm | |
| Daniel Kulp | Jul 7, 2008 2:48 pm | |
| Jukka Zitting | Jul 7, 2008 3:21 pm | |
| Davanum Srinivas | Jul 7, 2008 3:58 pm | |
| Davanum Srinivas | Jul 7, 2008 4:00 pm | |
| Jukka Zitting | Jul 7, 2008 4:39 pm | |
| Justin Erenkrantz | Jul 7, 2008 5:01 pm | |
| Roy T. Fielding | Jul 7, 2008 5:06 pm | |
| Roy T. Fielding | Jul 7, 2008 5:20 pm | |
| Davanum Srinivas | Jul 7, 2008 5:41 pm | |
| Carl Trieloff | Jul 7, 2008 5:57 pm | |
| Davanum Srinivas | Jul 7, 2008 6:15 pm | |
| Justin Erenkrantz | Jul 7, 2008 6:16 pm | |
| Daniel Kulp | Jul 7, 2008 8:05 pm | |
| Davanum Srinivas | Jul 7, 2008 8:25 pm | |
| Bertrand Delacretaz | Jul 7, 2008 10:50 pm | |
| Davanum Srinivas | Jul 8, 2008 3:07 am | |
| Davanum Srinivas | Jul 8, 2008 3:25 am | |
| Bertrand Delacretaz | Jul 8, 2008 4:08 am | |
| Davanum Srinivas | Jul 8, 2008 4:56 am | |
| Bertrand Delacretaz | Jul 8, 2008 5:17 am | |
| Davanum Srinivas | Jul 8, 2008 5:21 am | |
| William A. Rowe, Jr. | Jul 8, 2008 6:37 am | |
| Craig L Russell | Jul 8, 2008 7:38 am | |
| William A. Rowe, Jr. | Jul 8, 2008 7:45 am | |
| Noel J. Bergman | Jul 8, 2008 9:56 pm | |
| Noel J. Bergman | Jul 8, 2008 9:56 pm | |
| Noel J. Bergman | Jul 9, 2008 9:16 am | |
| Angela Cymbalak | Jul 9, 2008 10:40 am | |
| Paul Querna | Jul 9, 2008 10:46 am | |
| Paul Querna | Jul 9, 2008 11:02 am | |
| William A. Rowe, Jr. | Jul 9, 2008 11:20 am | |
| Davanum Srinivas | Jul 9, 2008 11:24 am | |
| Jochen Wiedmann | Jul 9, 2008 12:37 pm | |
| Aidan Skinner | Jul 9, 2008 1:13 pm | |
| William A. Rowe, Jr. | Jul 9, 2008 1:41 pm | |
| Jukka Zitting | Jul 9, 2008 3:24 pm | |
| Davanum Srinivas | Jul 9, 2008 4:42 pm | |
| Jukka Zitting | Jul 9, 2008 4:45 pm | |
| Jason van Zyl | Jul 9, 2008 7:28 pm | |
| Jim Jagielski | Jul 11, 2008 6:22 am | |
| Jim Jagielski | Jul 11, 2008 6:30 am | |
| Andrus Adamchik | Jul 11, 2008 6:40 am | |
| Jim Jagielski | Jul 11, 2008 6:53 am | |
| Jim Jagielski | Jul 11, 2008 7:04 am | |
| Andrus Adamchik | Jul 11, 2008 7:06 am | |
| Andrus Adamchik | Jul 11, 2008 7:07 am | |
| Brett Porter | Jul 11, 2008 8:41 am | |
| Brett Porter | Jul 11, 2008 9:06 am | |
| Brett Porter | Jul 11, 2008 9:35 am | |
| Jim Jagielski | Jul 11, 2008 12:23 pm | |
| Paul Querna | Jul 12, 2008 1:14 pm | |
| James Carman | Jul 13, 2008 5:26 am | |
| Henning Schmiedehausen | Jul 13, 2008 7:15 am | |
| Jim Jagielski | Jul 13, 2008 7:58 am | |
| Henning Schmiedehausen | Jul 15, 2008 3:34 am | |
| Niclas Hedhman | Jul 18, 2008 1:56 am |
| Subject: | Re: [DISCUSS] Do we really need an incubator? | |
|---|---|---|
| From: | Roy T. Fielding (fiel...@gbiv.com) | |
| Date: | Jul 7, 2008 5:06:32 pm | |
| List: | org.apache.incubator.general | |
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





