On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> 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
that.
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
that.
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.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
