incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <>
Subject Re: Outside view on incubator policy to initial committer list
Date Wed, 04 Oct 2006 16:34:37 GMT
On 10/3/06, Martijn Dashorst <> wrote:
> All,
> Just to pose an outsider view, being new to the ASF and not to hijack
> the discussion on the CFX/CeltiXFire, I would like to share my views
> on the policy of the incubator.
> From the documents I have read on the policy for entering, being
> inside and graduating from the incubator there is a lot of talk on
> process, but not a lot of explanation on *why* the process is in
> place, nor on how things are done.

I can understand all the gripes you bring up, and I'll try to address
each of them in turn...

> The first 'gripe' is the uncertainty for existing open source projects
> that want to join the ASF that their current contributors will be
> allowed to work on the project at Apache. The documents clearly state
> that such karma needs to be earned based on merit. It never states
> that merit earned in the past for the project can and *WILL* be used.
> This can only be found in heated discussions on this list.

Ok, so for the record, I don't think anyone involved in the incubator
thinks that ANY committer on an existing open source project that
moves to the ASF should lose that status in the process.  Unless
there's some sort of legal situation where the person can't sign the
CLA there should be NO reason that sort of thing should ever happen.

The reason there have been recent discussions about who gets commit
and who doesn't is rooted in a totally different situation (people who
were not formerly developers on the codebase in question being granted
commit as part of bringing the project to the ASF, without having done
anything to earn it).

> You will find in such discussions a variety of views, but the most
> restrictive, and in my opinion negative for existing projects is the
> one that wants only the mentors being on the initial PPMC/committers
> list, and have the incubating community earn their merit on apache
> ground using patches, mailinglist activity and whatnot, without giving
> the originating developers the karma to commit directly in Apache
> incubator SVN for the project. This is very damaging for a project
> that is already active outside the ASF and will grind it to a halt.

I don't think that anyone feels that this sort of precedure should be
followed for an existing open source project.  I certainly don't.

> If the prevailing opinion is that previously gained merit outside the
> ASF is taken into account, the policy should note that explicitly.

I believe that is the case, and I believe that it should be noted
explicitly in the policy.  There really should be two sets of
guidelines, one for existing open source projects, and one for
projects that are just becoming open source, IMO.

> The second gripe is the fact that only the Incubator PMC members of
> the PPMC have binding votes. I think I understand the reasoning for
> this, but it is not clear how the PMC members will excercise their
> binding votes. Will they affect the average day-to-day affairs within
> a community where the mentors have no direct affiliation with? Or is
> this only a guiding vote, for things such as:
>  - withholding a release when the podling is not considered ready
>  - not granting karma (with good backing reasoning)
>  - not taking in external code bases without the correct grant
>  - etc.
> The policy should make it clear that the PPMC chairs with the binding
> votes, only have that executive power to vote on such things regarding
> process.

I believe the problem here is a misunderstanding about how "binding
votes" are actually used in ASF projects.  In a normal ASF project,
who has a binding vote and who does not is almost never spoken of.
It's just not an issue.  When talking about applying a new patch or
ways to best fix a bug, an informal "+1" from a new contributor or
committer who is not on the PMC is just as welcome as one from a
seasoned PMC member.  It's NEVER been the case in my experience that
people would be held off from committing a change until enough
"binding" votes were gathered, that would be insane, and projects
would grind to a halt in that situation.

The only time that people need to care about making sure there are
enough binding votes are for things like releases, granting commit
access, adding people to the PMC, importing new codebases, stuff like

> The third gripe is that graduation has two components: a measurable
> component (active community, diverse, all legal matters resolved, no
> violating code, etc) and a non-measurable component (mature enough to
> be an 'apache' project). Given the sometimes extreme views expressed
> here (a nice read though :-), it is for an existing project really
> hard to trust such a process when you already have a healthy community
> which is basically put on hold whilst incubating, if you follow the
> incubator policy (and some egos) to the letter.

Yes, it is definately unfortunate that some components in graduation
are difficult to quantify, but there really isn't much of a way around

> Note that I understand the opposite views presented in the CFX case
> and I sympathize with all of them. I just wanted to express a view of
> someone coming from the outside, and looking at the process as it
> takes place.
> For existing projects it is a very hard decision to enter the
> incubator and the uncertain process until graduation. As the ASF you
> (we I should say) really have to put yourself into the shoes and
> clothes of the small community that is about to join a rollercoaster
> with unknown process, procedures, laws and above all, unwritten rules
> of conduct. It is quite something when a team has worked for 2 years
> two or three jobs worth of free time  on a project and it 'hands it
> over to the incubator'. Scary poo indeed.

I understand that it's definately scary, but keep in mind, you're not
really "handing it over", there's no "Us and Them" here, just Us.
Yes, you have to accept that for a period of time you'll need to run
some things by Incubator PMC members, who will make sure that big
ticket items (like releases) are following the guidelines that are
expected for ASF projects, but well, you'll be expected to follow
those same rules post-incubation at the ASF anyway, so assuming you're
actually doing things "right", getting 3 people to say "yep, looks
good" shouldn't be that huge of a problem.

Could it be easier?  Sure.  We could certainly have better
documentation (although what's there now is light years better than
what used to be).  We could have more Incubator PMC members voting on
releases.  But in the end I don't think the reality of being an
incubator project is as bad as it may look at first glance.


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

View raw message