incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <>
Subject Re: [VOTE] Graduate Derby from the incubator
Date Fri, 22 Apr 2005 11:47:22 GMT

On Apr 18, 2005, at 12:59 PM, Cliff Schmidt wrote:

> On 4/18/05, Rodent of Unusual Size <> wrote:
>> Brian Behlendorf wrote:
>>> Wouldn't "how can we increase the number of new developers on Derby  
>>> while
>>> still in incubation" a better question to ask?
>> I think only if the answer to 'does Derby need more committers before
>> it can graduate' is 'yes.'  Participation is growing nicely, but the  
>> Derby
>> PPMC is being careful not to hand out commit access like candy.
> I definitely don't think the PPMC should lower the standard for commit
> access, nor do I think the Incubator PMC should lower the standard for
> Incubator graduation.
> I'm really surprised we're even talking about graduation before Derby
> has met the most basic rule of three independent committers (didn't we
> just have a thread on this a few weeks ago about log4net?).  Once that
> has been met, I'd expect a discussion about whether the project has
> the kind of community that could continue to maintain and evolve the
> project even if one individual / company stopped contributing to it.

I'd love to see what some people think about the community - go look at  
the lists.   That is what I looked at first, and it gave me confidence.

> I know that there are different opinions on the second point, but I
> believe the three committer rule is pretty widely agreed upon.

Well...  the three committer rule is (although there are exceptions for  
corner cases...), but we have a bit of dissonance between how we are  
defining "independent committer" here  
Incubation_Policy.html#Minimum+Exit+Requirements) and the general  
Apache custom of leaving our employers "at the door" and participating  
as individuals who have earned their karma through individual merit and  
demonstrated interest.  (Yes, in incubator one might argue that isn't  
the case always...)

For example, we currently claim that an individuals ICLA is sufficient  
representation of ability to contribute.  Is it?  Clearly, we are  
implicitly stating here that it isn't - that there is some other  
binding on these committers by their employer that puts the project  
health at the risk by the employer.

If that's so, doesn't it behoove us to ask for a CCLA for employed  
committers since we clearly believe that employers are capricious and  
can change their mind, and w/o the formal IP agreements of the CCLA....

(Reality is that employers *can* change their mind, of course.)

In the end, I think it's a judgment call, rather than a hard and fast  
rule, because I would hate to have to constantly be policing projects  
at the ASF and sending them back to incubation if they failed to  
satisfy the 3 "legally independent" committer rule.  It's absolutely  
clear that Derby needs a more diverse committer base, but I still would  
be ok with it graduating to DB because of what I see as the diversity  
in it's community. There are a large number of individuals that  
participate in the project, and there are commercial interests besides  
IBM around the codebase.  It's even been a featured subject in The Bile  
Blog. :)

I respect people's judgment here and will work to help get more  
committers (I could try to be one, but it wouldn't help as Jeremy and I  
work for the same company), but I do think we need to keep this facet  
of incubation in context, and for me it's a balance of aspects,  
including where the project is going (i.e. to an existing PMC, or a  

We also may want to be explicit by what we mean by "legally  
independent" committers.

>> I guess the basic question would be, 'Does keeping Derby in the  
>> incubator
>> add any value anywhere?'  At this point I feel moderately strongly  
>> that
>> it doesn't, but that's just me -- and I can be convinced otherwise.  
>> :-)
> I'm primarily concerned about the devaluation of the Apache brand by
> lowering our standards for what it means to have a strong, diverse
> community.

I'm reading this to mean that you don't think that Derby has a strong  
diverse community.

I think it has a diverse community.  However, I don't think we have any  
good way of measuring that, or if things like the following are  
quantitatively meaningful.  We can look at dev mail list traffic, info  
taken from eyebrowse :

Derby : # authors = 228, # msg YTD : ~1100
Beehive : # authors = 144, # msg (Oct04-Jan05) : ~1300 (is there a  
problem w/ archive here?  Dropped off in feb05 so didn't want to do YTD  
as a compare, as then it's only ~400)
Directory : # authors 171, # msg (Oct04-Jan05) ~1800 (used same date  
range as it exited in march)

So it has 33% more unique authors on it's dev list than Directory which  
graduated, and has has "order of magnitude similar" volumes of traffic.  
(1800 is significant %-age more than 1100, but there was a weird 900  
message month for Directory in Dec, I think...)

What it doesn't have an "employer-diverse" committer set, but see merit  
in the argument that it wouldn't hurt to be graduated.  I had the very  
similar concerns about Geronimo - that it needed more committer base  
growth - that were IMO for some similar reasons :  a) difficult subject  
matter that required some measurable expertise and b) a bit of  
conservatism by some committers.  It's still not where I think it  
should be, but it's growing, and sometimes it's just about having the  
time to grow, I guess.

Anyway, I just wanted to point out the inconsistency we have regarding  
employers, and that we're mixing up community diversity and committer  
diversity, and that a lot of this is a judgment call, taking many  
things into account....  Now if Derby would just solve this by getting  
that 3rd committer.... :)


> Cliff
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Geir Magnusson Jr                                  +1-203-665-6437

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

View raw message