incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: LDAP changes to support podlings
Date Mon, 16 Jan 2017 18:31:20 GMT
Not sure what was the decision to be made here, but +1 to all suggestions.
All of PPMC as podling owners makes sense to me as long as private@podling
is notified.

Great work!

On 16 Jan 2017 6:05 pm, "Sam Ruby" <> wrote:

> 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 application.
> 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:

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