On 02/06/2008, Henri Yandell <[EMAIL PROTECTED]> wrote: > On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
