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 https://incubator.apache.org/projects/ 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:

https://whimsy.apache.org/roster/ppmc/

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: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to