On Fri, Sep 2, 2016 at 1:06 PM, Mark Thomas <ma...@apache.org> wrote:
> On 02/09/2016 17:41, Sam Ruby wrote:
>> 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.
>
> (from the peanut gallery)
>
> +1 to pushing it down to the podling. If I am reading this proposal
> correctly, the worst they can do is grant an ASF committer write access
> to their svn area.

I should probably have called that out.  You are correct, it is only
possible to add existing committers to an LDAP group.  I would hope
that that would go a long way to addressing John's concern.
Additionally, the web interface could provide helpful text describing
the process, and provide links to where more information can be found.

Also, mistakes can readily be reverted.

In all, with the website providing helpful guidance, and with
notification and the oversight this enables, this should provide the
opportunity for "teachable moments" and move the PPMC towards
self-government.

>> 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.
>
> The key being "where it may be desired".
>
> I'd prefer to see us moving towards coarser technical access control and
> using social controls for the fine-grained aspects across the ASF.

I'm not sure where I fall on that spectrum.  For example, while I
would support enabling those listed as being a member of a podling to
adjust the roster for that podling, and while I do believe that
notification to PPMCs would provide an effective social control, I
would be mildly opposed to allowing members of any podling to modify
the roster to podlings that they are not a member of.

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

- 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