On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> wrote:
> For background, if you go to the Apache phonebook > (https://people.apache.org/phonebook.html) 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: > > > https://github.com/apache/infrastructure-puppet/blob/deployment/modules/subversion_server/files/authorization/asf-authorization-template > > 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: > > > https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo > > 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 > following: > > https://whimsy.apache.org/roster/group/ > > 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. > My vote would be for mentors to be able to do this. The podlings don't know enough yet to manage this on their own. I would be concerned of missed process steps if the podling themselves could do it. > > 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. > Could this lead to the eventual removal of podlings.xml ? Does any of this have a relationship to projects.apache.org ? > > 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
