incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [RT] Learning from the facts ( Re: Undermining the Incubator )
Date Wed, 14 Jan 2004 11:54:31 GMT

Trying to get constructive on this, by basing the replies on *facts*, 
and not opinions taken from an experience done long ago.

First of all, let me remove the false statements:

Andrew C. Oliver wrote:
> The project must vote (or at least should). The Incubator PMC must
> vote. The accepting project or board must vote. That¹s three houses
> voting for project promotion.

Wrong. The Incubator does not vote.

To get in the Incubator you need two parties agreeing, that is the 
project and Apache. For Apache the vote can come from a PMC or the 
board, but a further vote from the Incubator is not needed.

I don't see how we can get down to less than two votes.

Rich Bowen wrote:
>> The goal of the incubator is to help people in. Part of that is, 
>> necessarily, determining that some projects maybe should not come
>> in. I don't see this as a bad thing.
 > I do.  Interested sponsoring members should determine that.  Not
 > some...."administrator" or committee of them.

And that's what happens. *If* there is no PMC that accepts it the 
Incubator will vote for it. A single member cannot accept a project for 
Apache AFAIK, but a PMC may (the Chair can act on behalf of Apache).

> a fuzzy idea with many different opinions on when a project gets out
> or not.

There is no "opinion". The decision is based on the facts exposed in the 
STATUS file.

> * Exposes the Foundation to undue legal issues by protecting projects
> PRIOR to their legal issues being sorted out.
> I just favor not accepting them at all until they've done their
> work.

This should be the case. Auditing on codebases has to be done *before* 
any code enters Apache. People *sign* CLAs that state that they have the 
right to put that code in.

So we do *not* accept that a tainted codebase enters our CVS.

If problems occur after it has been committed, we must ensure that the 
issue is solved ASAP, eventually also resorting to extreme measures like 
revoking commit privs or closing the project down. Exactly like any 
other Apache project.

Note that is a project is to enter the Incubator, it has Apache members 
that stand by it, and guarantee that the project is not a "fake". You 
have been saying that we should stand by the members that want the 
project in, so why not in this case?

Now for the constructive part.

>* Hurts already healthy communities by putting them back into an alphaish
> If I had a mature project ready for production which had been so for
> a number of years and then I said "I want to be part of Apache"....  You'd
> put it in the "incubator" and tell the world it needed incubation?  Pretty
> ugly perception that pushes about a mature project.

I'd like everyone to think about this comment, as it has been said 
basically by all projects coming through the Incubator, in one way or 
the other. OTOMH the last have been Axion and Logging projects.

MHO is that we do not require that a project be "under" the Incubator 
urls and resources. This was said to ensure that they don't misuse the 
"regular" Apache brand, but if it remains "outside" of Apache during 
Incubation, the problem is equally solved.

One thing is having access to the Incubator for the status file and 
creating Apache resources, which has to be done, and another is making 
the project "operate" under these same resources during Incubation, 
which is not necessary.

What do others think?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message