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