incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject LDAP changes to support podlings
Date Mon, 16 Jan 2017 18:05:33 GMT
TL;DR: We need to decide, for each PPMC, who gets to update the PPMC 
list and where notifications to be sent on changes.


Background: we have a variety of tools that need access to PPMC member 
lists, including but not limited to: gitbox, phonebook, ponymail, 
roller, sonar, subversion, and whimsy.

The plan is to consolidate all of this to LDAP.  Previously, a number of 
'auth groups' were migrated from the subversion puppet definition to 
LDAP.  The plan is to do podlings next, and ultimately change the way 
PMCs are stored in LDAP.

Currently the 'best' (as in machine readable) list of ppmc member 
information is in the subversion puppet definition - even for podlings 
that don't make use of subversion as this currently is the most 
expeditious way to get ppmc member lists to show up in the the phonebook 

The cleanest list of mentors can be found in podlings.xml.

More complete, but less machine readable, and not always consistently 
maintained information can be found on the individual pages.

gitbox, phonebook, ponymail, roller, sonar, subversion
Current status: for ppmcs that have lists in the subversion puppet 
definitions, those lists have been loaded into LDAP, and augmented with 
mentor information from podlings.xml.  A list of all current podlings 
can be found here, and those that have been loaded contain links to 
individual pages:

These pages are currently read-only, and contain links to the project 
page, mailing lists, and prior published reports.


Near future: what we need to resolve is who should be the 'owners' and 
who should be the 'members' for each PPMC.  These are LDAP terms, and 
they can be disjoint, overlapping, or even identical.

The key point is that owners can change membership of the lists, and 
members are what gitbox, ponymail, roller, sonar, and subversion will 
use for access control.

No matter what is decided, owners will be limited to adding and removing 
people who are already committers; adding new ids entirely will still 
require using the new account request web page.  Furthermore, all change 
will trigger notification to, at a minimum, root@.  Additionally 
notifying the individual affected, the private list for the podling, and 
or the private list for the incubator are possibilities.

Given that these controls will be in place, allowing all members to also 
be owners should be safe.  Limiting owners to only mentors would also be 
a valid choice.  This need not be the same choice for all PPMCs, but it 
probably would make life (and tooling) easier if it were.

Once this decision is made, the whimsy roster tool will be updated to 
allow owners to update lists, and those owners will be asked to do so. 
At that point, the subversion access lists in puppet will be converted 
over to LDAP, and the infra team will stop accepting JIRA requests to 
maintain these lists.


Not so distant future: the tools mentioned above will all be updated to 
use the common LDAP definition for podling membership.  As an example, 
the phonebook application will include all podlings, with data 
automatically updated within hours of a change.

The whimsy roster tool currently contains links to mailing lists and 
posted board reports.  It could be updated to include links to other 
tools ranging from subscribing and unsubscribing to mailing lists to 
static sonar analysis.

New tools could be built using this data: for example, all of the data 
needed to draft board resolutions related to graduation could be 
gathered from LDAP and podlings.xml.


Further in the future: PMC definitions will be changed to match the way 
PPMC definitions are done.  At the present time, only PMC chairs can 
update PMC member and committer lists -- even for PMCs to which they 
don't belong.  Other PMC members who aren't PMC chairs can't update 
their own lists.

- Sam Ruby

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

View raw message