You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2006/06/01 03:08:40 UTC

Re: Code based on a one man show is bad news ( was: Re: [Fwd: svn commit: r408142 - ... )

Enrique Rodriguez wrote:

> Trustin Lee wrote:
>
>> On 5/25/06, *Enrique Rodriguez* <enriquer9@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>      > Are my concerns founded?
>>
>>     Yes, your concerns are founded and I will work to alleviate them
>> ASAP.
>>     I am very much looking forward to community involvement.  It was
>> never
>>     my intention to be a one-man show on OSGi and I thought that
>> working to
>>     grow the Felix project was an excellent sign of that.  The OSGi
>> R4 specs
>>     weigh in at 1,100 pages so the more people reading and grokking the
>>     spec, the better.
>>
>> I think Alex's concern is not just about the OSGi service but about
>> all protocol providers such as Kerberos.  I strongly agree with Alex
>> though it is true that all of us didn't have special interest in
>> those protocol providers.  Now, it's time for all of us to get
>> involved into those components to make sure it belongs to the
>> community.  Until all of us are ready to support them, I think you,
>> as the best guy, need to support users actively and keep writing
>> documentation for them.
>
>
> Hi, Trustin,
>
> I am really excited to hear that you are hoping to get more involved
> in not just OSGi but also the "realm controller" protocol providers. 
> While I work to alleviate the user support issues and to write
> documentation specific to the provider implementations, a really great
> way to start to come up to speed on DNS, DHCP, Kerberos, Change
> Password, and NTP is by reading the IETF specifications that these
> protocols are based on.  If you wanted I could put together a reading
> list of the relevant IETF RFC's, as well as the page numbers and
> chapters of the OSGi R4 specification, since much of the R4 spec does
> not apply to our project.

This is great Enrique.  Another thing we need to consider is how we're
going to attract others perhaps outside of our existing network to
partake in these projects.

Perhaps we can lower the barrier of entry for new committers that show
and eagerness to work on these protocol providers. 

Alex