Actually adding gstein this time.
- Sam Ruby
On Wed, Sep 21, 2016 at 10:17 PM, Sam Ruby <ru...@intertwingly.net> wrote:
> cc += gstein
> On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes <st...@apache.org> 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 people.apache.org 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 https://whimsy.apache.org/officers/acreq/; it loads much
> faster than https://id.apache.org/acreq/; if you like it, spread the
> - Sam Ruby
>> On 2 September 2016 at 18:52, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <johndam...@apache.org>
>>>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> 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 projects.apache.org ?
>>> At a minimum, both would derive information from a common source.
>>> My understanding is that the focus of projects.apache.org 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: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>> Stian Soiland-Reyes
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org