You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2008/06/01 17:59:48 UTC

RE: maven repository

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.

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.

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.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: maven repository

Posted by "Noel J. Bergman" <no...@devtech.com>.
James Carman wrote:

> Noel J. Bergman wrote:
> > 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.
> I apologize for being so verbose.  This is probably not the correct
> forum to discuss those changes at that level of detail.

No need to apologize.  As I said, I agree with you.  I just didn't want to
delve into details when we don't even have support from Maven, yet.  :-)

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: maven repository

Posted by James Carman <ja...@carmanconsulting.com>.
On Sun, Jun 1, 2008 at 11:59 AM, Noel J. Bergman <no...@devtech.com> wrote:

> 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.
>

I apologize for being so verbose.  This is probably not the correct
forum to discuss those changes at that level of detail.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: maven repository

Posted by sebb <se...@gmail.com>.
On 02/06/2008, Henri Yandell <fl...@gmail.com> wrote:
> On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <no...@devtech.com> 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.

It's no longer the same project.

The original project can stay in central.

Once the project has been rebranded as ASF and passed through the
other changes required by the incubation process it can go back into
central as the new project.

>  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.

Which is one reason why the ASF brand is more trusted than some.

>  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.

I don't see it that way.

I see it as protecting the ASF name.

>
>  > 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.
>
>  Hen
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: maven repository

Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <no...@devtech.com> 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.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org