incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: maven repository
Date Mon, 02 Jun 2008 06:50:28 GMT
On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <> wrote:
> Henri Yandell wrote:
>> Noel J. Bergman wrote:
>> > I really do not know why we have to revisit this same topic year after
> year
>> > after year.  We do not want people to be using any Incubator artifact
>> > without explicit knowledge and action, so we do not want them polluting
> the
>> > standard repository.
>> And as with every year I'll call "BS" :)
>> We do want people to use them, and we do want them on the standard
>> repository. They are releases.
> They are *Incubator* releases.  And we do care that people are aware of that
> status.  You are free to try to convince the Board and/or Membership to
> change the Incubator's mandate, but until then that is the issue.

Where is that mandate defined? I see nothing in the original
resolution to imply this. To my understanding, treating Incubator
podlings differently from Apache subprojects is an invention of the
Incubator PMC.

> We want awareness and consent by the end-user, not "hinderance."  This is
> analogous to the multiverse repository (or even a PPA repository), vs main
> and security in Ubuntu-land.  A user must explicitly choose to allow
> artifacts found in repositories other than main and security.  There are
> disclaimers associated with the repositories.

Not a great analogy though.

Main = central.

Project A is in central. It goes to Apache. It can no longer be in
central because it is no longer a trusted project until Apache bless
it. It's a nuts policy.

Project B does not exist and is being created. Anywhere else, it goes
into central. At Apache, it has to sit it out in its own sandbox
waiting to be considered acceptable. That's if it is created in the
Incubator (or a previously private project that is going public via
the Incubator), or if it is in Labs where any releases have to happen
outside of Apache as they can't happen inside, but not if it is a new
subproject to an existing Apache project.

We cut off our nose to spite our face.

> FWIW, I agree with James that we would use signing to be more fine-grained,
> but didn't want to go into that degree of detail in the earlier discussion.
>> If the nays get their way though - the solution is easy. Release your
>> incubating release outside the ASF and get it sync'd from there to the
>> central repository.
> Before suggesting that projects intentionally circumvent ASF procedure, you
> might want to discuss that with Justin and/or Dave Johnson, since they spent
> a lot of time dealing with it for Roller.

I seem to remember spending a lot of time on it too - it had nothing
to do with this issue but with the fact that it wanted to include an
LGPL dependency. The solution was the same, release outside the ASF
until it passes the ASF bar - the difference is that this thread
claims there is a bar on ASF releases beyond the legal policies and
the 3 +1s.


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

View raw message