www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Date Wed, 21 Jan 2015 14:58:12 GMT

> On Jan 21, 2015, at 12:47 AM, jan i <jani@apache.org> wrote:
> 
> On Wednesday, January 21, 2015, Alan D. Cabrera <adc@toolazydogs.com <mailto:adc@toolazydogs.com>>
wrote:
> 
>> 
>>> On Jan 20, 2015, at 4:03 PM, Marvin Humphrey <marvin@rectangular.com <mailto:marvin@rectangular.com>
>> <javascript:;>> wrote:
>>> 
>>> On Tue, Jan 20, 2015 at 3:57 PM, sebb <sebbaz@gmail.com <mailto:sebbaz@gmail.com>
<javascript:;>>
>> wrote:
>>> 
>>>>> But committers added after the podling
>>>>> entered incubator might, but need not be PPMC.
>>>> 
>>>> That is news to me; I thought the idea was building community rather
>>>> than acquiring developers  but I could be wrong.
>>> 
>>> It's up to the community.  This is an old debate, and some people feel
>>> very strongly one way or the other.  The Incubator accommodates both.
>> 
>> This is why we need LDAP groups for PPMC members.  I’m glad we’re on the
>> same page now.
> 
> 
>> Can we all agree that we need to put this into LDAP?
> 
> 
> I agree with you  that LDAP is the right place for such information, and I
> do not see so many podlings fail that it should be a major concern. However
> I think a discussion on general@i.a.o <mailto:general@i.a.o> is needed.
> 
> If PPMC/committers maintenance of a podling is moved to LDAP, the mentors
> and/or PPMC will no longer be able to maintain it them self. The script to
> update LDAP is only available to officers (chairs) and infra, meaning we
> move a task and the incubator chair needs to agree to that.

You describe a tooling problem, something that can easily be remedied in a straightforward,
secure, manner.

Look, this is not a new problem that has not been solved elsewhere thousands of times before.


Regards,
Alan


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message