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" <ru...@intertwingly.net> 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 > 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 > >
