incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [discuss] Move podling rosters to LDAP
Date Thu, 22 Sep 2016 02:17:29 GMT
cc += gstein

On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes <> wrote:
> Did this conclude..? Just in case it didn't, here's my +1 as well to
> make podling membership be in proper LDAP groups; with email
> notifications to private@podling as you mention.

This did not conclude, but you picked an opportune time to resurrect
this thread with Greg joining the infrastructure team.  In fact, I was
planning to restart this thread for exactly that reason; thank you for
doing it.

My assessment previously was that there wasn't enough demand at the
time to overcome inertia.  This change will undoubtedly break things
temporarily, but nothing that can't be fixed quickly.

> (I am lucky enough to have faced the asf-authorization-template a
> couple of times :) )

Join the club. :-)  The current process sucks, doesn't it.  :-)

> Ensuring is updated would also make it easier for
> podlings to refer to a canonical list of who are their members; which
> would work somewhat the same way after graduating.

That's part of the discussion I would like to have.  I'm proposing
that members of the podling can update the group.  Currently only PMC
chairs can modify PMCs.  And furthermore, PMC chairs can modify *any*
PMC, not just the one(s) they chair.

I'd like to change this so that PMC members can modify their own
group.  And I believe that the increased notifications that this tool
will provide will enable proper oversight.

I also believe this to be fully in line with the President's (Ross's)
desire to enable self-service.

But a change of this magnitude to the way that we operate is something
that requires a critical mass of support.  Thanks for lending your
voice to this discussion.

> Letting podling members modify the group themselves is good (as you
> said the worst they can do is add another committer), as long as we'll
> keep the account creation process under the hands of ASF Members (as
> it is now).

ASF members and officers.

By the way, if you ever want to submit an account request, you might
want to try; it loads much
faster than; if you like it, spread the

- Sam Ruby

> On 2 September 2016 at 18:52, Sam Ruby <> wrote:
>> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <> wrote:
>>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <> wrote:
>>>> 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.
>> See Mark's comment, and my response to 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 ?
>> It could lead to where-ever the IPMC wants to go. :-)
>> My preference is that the canonical definition be in SVN, git, LDAP or
>> some such, and that tools like whimsy remain only a convenient
>> mechanism to update these definitions.
>>> Does any of this have a relationship to ?
>> At a minimum, both would derive information from a common source.
>> My understanding is that the focus of is to
>> provide a public-facing and read-only interface to this data.
>> The whimsy roster tool would provide an authenticated read-write
>> interface to this data.  And a non-exclusive one.  Other tools could
>> be written that update that information.
>> - Sam Ruby
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Stian Soiland-Reyes
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message