directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [discussion] Lowering barrier for perspective committers
Date Thu, 06 Jul 2006 20:13:54 GMT
Alex Karasulu a écrit :

> Hi all,

Hi you :)

> Our Problems
> ============
> The number of active committers on Apache Directory Server is 
> dwindling and we have many areas where a single developer has been 
> working alone.
> Some email threads have tried to address the issue of the lack of enough
> committers in specific areas: see threads [0] & [1].  So we are
> suffering mostly in the following areas:
> o OSGi effort,
> o Kerberos protocol development,
> o Changepw protocol development,
> o DHCP protocol development, and
> o DNS protocol development.

I will add :
  o Apacheds Core fix and improvment

> Even the work being done on the LDAP protocol has too few people
> involved.  Right now we have the following active LDAP committers:

> We certainly need more people to be actively involved.  I see many
> talented individuals that have been lurking, sometimes getting involved
> to work on particular problems as they get the itch.  I'd like to
> welcome these people and invite them to work on the core of the server
> with us.

Yeah !

> Sometimes we're finding it hard to keep up with the
> contributions from these folks.  Some are very excited in working with
> us and we often find our selves lacking the time to engage them.

Very true...

> As the PMC chair, I see these circumstances as warning signs.  They 
> reflect a weakening community.

We are currently weak... We need some committeroïds !

> Possible Solutions
> ==================
> Getting existing committers more involved and working on different parts
> of the server is not so easy.  Knowledge transfer is needed to get them
> and even others involved in parts of the server they are not accustomed
> to.  For this I personally will start conducting some classes and
> preparing materials for those interested in learning about the internals
> of the server on some interactive medium.  The materials for these 
> classes can also serve as a documentation update for our website so 
> others can follow these trails.  It would be nice if other committers 
> can also give some tutorials in their respective areas of expertise.

I sure have to write a hell *lot* of documentation about the ASN.1. The 
main problems with this lack of documentation are :
- difficulties to get new committers being able to modify the code
- difficulties for current committers to fix current errors
- risk that a committer left the project for any reason, without anyone 
being able to cope with the committer's code
- risk to have code being committed without control and driving the 
server in the wrong direction.

> As for new committers, I think we need to lower the barrier for
> committership while safely integrating these committers into our
> committer base.  

This is very true also for current committers :) I bet that it's almost 
impossible for any of you to fix a pb in shard-asn1 now ... (even for 
me, it's barely possible :)


> For this I propose a committer mentorship program while lowering the 
> barrier of entry for new committers.


> The idea is to use a review then commit (RTC) process on main branches 
> of development for these new "probationary" committers (a.k.a. probies).

Probitters ?

>  Commits to personal areas in the sandbox do not apply.  Hence any 
> commit to main branches must be approved by a mentor.

Well, I guess that at some point, we may want to define "secured zones" 
like apacheds-core or shared-ldap, which should be protected by a RTC 
policy, for any committers. Let say we could do that when 1.0 is released.
The idea is that if a probitter has some code to commit, it can do it in 
his own branch before proposing the commit. It will allow the Mentor to 
test the fix before including it into the trunks. The main problem for 
us is that the code base is pretty impressive (200 000 SLOCs), and 
really difficult to manage. The apacheds core module is by itself more 
than 20% of this total, and it's really very intricated. We may need 
more layering

>   The same rules apply for a veto.  A mentor has the responsibility to 
> review the work of a probie in a timely fashion for this process to 
> work however the probie can file the JIRA, apply approved patches and 
> close it after the approval using their own steam.  This way we reduce 
> the amount of work existing committers have to do on behalf of 
> consistent contributors. Also the person with the itch can drive the 
> change instead of being blocked waiting for a committer to get to 
> their JIRA issues reviewed then applied.


> Such a program gives regular contributors more power to affect the 
> code base and creates a smoother path towards their becoming 
> committers thanks to a lower barrier.
> Possible Drawbacks
> ==================
> o Needs some upfront initiative.
> o More process to deal with?
> o Will probies feel like second class committers? Are there social 
> ramifications?

I don't think so. I do think that "real committers" must sometime behave 
like probitters. When you are modifying a piece of code you don't 
understand fully, it's good to have a mentor giving an approval.

> Conclusions
> ===========
> This idea is not exercised at the ASF in any project explicitly 
> however some elements of it appear in various communities.  

I think HTTPd is working this way, plus a vote for stable versions.

> Usually communities at the ASF especially trust new committers that 
> somewhat distrust themselves with code they are not familiar with.  A 
> good new committer is someone who besides being consistent and active 
> is careful enough to presume they are not always right, 

And maybe you must assume that you may sometime be right, even if doubt 
should be your Mr Hide.

> especially with changes to unfamiliar code.  Culturally, elements of 
> such a process may unofficially be practiced at various projects 
> within the ASF.  The problem with this approach is, the new committer 
> is trusted yet expected to engage others if they are unsure of 
> themselves.  This IMO puts a lot on the shoulders of new committers.
> Considering our less than optimal situation, WRT the number of 
> committers in this community, I think we need to formalize this 
> process to facilitate more involvement from the contributor community 
> at large.  Consider it a precaution against an active committer 
> drought taken under extreme conditions.  I would like to vote on 
> giving this process a try for a quarter to experiment and see how it 
> works.

Vote !!!

> Hopefully formalizing this process under these circumstances will pull 
> contributors on our periphery closer to the core team of active 
> committers leading to a healthier community.
> Thoughts? Comments?

Well, we also need more integration tests. Integration tests build 
confidence for committers, being newbies or veterans...


View raw message