incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject [discuss] Move podling rosters to LDAP
Date Fri, 02 Sep 2016 16:41:59 GMT
For background, if you go to the Apache phonebook 
( and click on the "Podling 
name" input field and click on enter you will see an incomplete list of 
podlings.  If you click on a podling, you will see a list of members for 
that podling.

The ultimate source for this is the following file, which is nominally 
used to define access control to portions of svn repositories:

In some cases (like commonsrdf) the list is in that file only in order 
to populate the phonebook.

The workflow for updating these lists is documented here:

Or, and perhaps more commonly, by entering a JIRA and having the 
infrastructure team make the change for you.


More generally, over the years the ASF has accrued a number of ad-hoc 
lists of members.  In addition to PMCs and committees, we have the 

I previously moved a number of non-podling svn authorizations to LDAP, 
and they show up on this list as "LDAP Auth Group"s.  As currently 
defined, members of those groups can use the web interface to add or 
remove members, and the private list for the associated PMC will be 
notified of any changes if there is an associated PMC, or the list of 
members (including the person added or removed) will be notified if 
there is no associated PMC.

This seems to be working well, so I'd like to move on to the next stage: 
moving podling lists to LDAP.


The first stage would be migrating existing lists to LDAP.  This will 
require some small changes to whimsy and the phone book application. 
The whole effort will only take a few hours and be spread over a few 
days elapsed time.

To prepare, we will need to decide who gets to modify these lists, and 
who gets notified.  I propose that members of podlings be able to modify 
the list, and the private list associated with that podling be notified 
on changes.  Alternate choices would include mentors for the podling, or 
the IPMC.  Given that notification facilitates oversight, I encourage 
this to be pushed down to the podling, but will go with whatever the 
consensus turns out to be.

The second stage would be to define an interface for adding (and perhaps 
removing) podlings.  This could be limited to the IPMC and the web 
interface could ensure that it is only possible to create entries that 
are present in podlings.xml.

Ultimately, I would like the roster page for a give podling to enable 
the updating of relevant information about that podling independent of 
the ultimately location of that data.  For example, adding or removing a 
mentor could be done via this interface, and the result would be an 
update to podlings.xml.


Immediate benefits for this would be a reduction in routine requests 
made on our infrastructure contractors, and the potential for lists 
being kept more up to date by enabling those most directly affected by 
the correctness of these lists to make changes.

Longer term this change would lay the groundwork for more fine-grained 
access control whereever it may be desired: not just for svn, but also 
for web pages, git, and any other location that can be configured to use 
LDAP to obtain ACL information.

- Sam Ruby

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

View raw message