On 3/16/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
Craig, the point is that downstream users may not be required to add a <repository> setting. If I depend on A, and A depends on IncubatorB, I would get IncubatorB without needing a <repository> setting if the pom for A has that setting in it.
An argument for dumping the entire set if distinction between incubating and non-incubating projects, instead of just some of them.
That's pretty much my point. If there are huge use cases where users DON'T have to put a repository entry in, then why are we bothering having a separate repository? That's bandwidth/processes/etc.. on p.a.o that we consume for no reason. Push that to central.
Performance concerns should not drive policies. Policies should drive practices, which should drive efficient implementations. The policy I'm most concerned with in this thread is whether incubating project releases are "official" Apache releases, that provide the ASF legal protections to the authors, and assurances to the downstream users that ASF has done its usual vetting of these releases. If we indeed want that to be the result, then sure ... get rid of the incubating repository, get rid of the restrictions on posting incubating releases to the central repository, and so on. But also get rid of all the other useless crap (requiring "incubating" in version numbers etc.) that does not accomplish anything useful in this scenario. Is everyone in ASF willing to be comfortable with the ASF stamp of approval on a project that might still be in the process of vetting code provenance, or still checking licenses, but chooses to do an incubating release anyway?
J. Daniel Kulp
Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
