You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Sam Ruby <ru...@intertwingly.net> on 2016/09/02 16:41:59 UTC
[discuss] Move podling rosters to LDAP
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Sep 21, 2016 at 9: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
>
From the thread, I don't believe that I've got any action items, or
feedback. Just to remove roadblocks where I can.
Cheers,
-g
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@intertwingly.net>.
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
> word.
>
> - 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 <jo...@apache.org> wrote:
>>>> 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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/0000-0001-9842-9718
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@intertwingly.net>.
On Thu, Sep 22, 2016 at 12:08 PM, Stian Soiland-Reyes <st...@apache.org> wrote:
> Does means podlings will also need to define both a $podling and
> $podling-pmc group?
It doesn't require that... it doesn't preclude that. My original
proposal was not to add that separation, but such could be handled if
it were desirable.
If you go to https://whimsy.apache.org/roster/group/, you will see a
number of LDAP Auth Groups interspersed amongst the various other
types of groups (if it helps, click on the column heading to sort by
group type). Any member of those groups can modify the groups that
they are a member of using that web interface.
If you go to this page, you will see a number of PMCs:
https://whimsy.apache.org/roster/committee/. PMCs have separate lists
for members of the PMC and committers. Currently, only pmc chairs can
modify PMC lists (and not just limited to their own). My preference
would be that any PMC member could modify the PMCs that they are a
member of.
I started with non-podling LDAP Auth Groups. I would like to do
Podlings next, followed by PMCs. From an implementation perspective,
I don't care where in the spectrum between LDAP Auth Groups and PMCs
Podlings will fall, but for the moment I don't see a need for
separation between owners of podlings and members of podlings. I can
see an argument for mentors being owners (and the only ones who can
modify membership), but my personal preference would be for members of
Podlings being the owners, with mentors providing oversight.
> Many podlings don't have a clear distinction - at least not in listings.
> Perhaps they should..
From a technical point of view, that's not an issue. So the question
is what does the IPMC want here?
- Sam Ruby
> On 22 Sep 2016 3:17 a.m., "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
>> word.
>>
>> - 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 <jo...@apache.org>
>> wrote:
>> >>> 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-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes
>> > http://orcid.org/0000-0001-9842-9718
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Stian Soiland-Reyes <st...@apache.org>.
Does means podlings will also need to define both a $podling and
$podling-pmc group?
Many podlings don't have a clear distinction - at least not in listings.
Perhaps they should..
On 22 Sep 2016 3:17 a.m., "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
> word.
>
> - 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 <jo...@apache.org>
> wrote:
> >>> 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-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > http://orcid.org/0000-0001-9842-9718
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@intertwingly.net>.
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
word.
- 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 <jo...@apache.org> wrote:
>>> 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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Stian Soiland-Reyes <st...@apache.org>.
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.
(I am lucky enough to have faced the asf-authorization-template a
couple of times :) )
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.
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).
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 <jo...@apache.org> wrote:
>> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <jo...@apache.org> wrote:
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by "John D. Ament" <jo...@apache.org>.
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [discuss] Move podling rosters to LDAP
Posted by "John D. Ament" <jo...@apache.org>.
Just wondering - do the old mail archives support this, or is it any IPMC
member can access the podling private lists (and the PPMCs can't?)
If the PPMCs can... can we just replicate that permission?
On Tue, Oct 11, 2016 at 9:29 PM Sam Ruby <ru...@apache.org> wrote:
> On 2016-09-02 12:41 (-0400), Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > 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.
>
> .. and mailing lists. See:
>
> https://issues.apache.org/jira/browse/INFRA-12744
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@apache.org>.
On 2016-09-02 12:41 (-0400), Sam Ruby <ru...@intertwingly.net> wrote:
>
> 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.
.. and mailing lists. See:
https://issues.apache.org/jira/browse/INFRA-12744
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Sam Ruby <ru...@intertwingly.net>.
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
Posted by Mark Thomas <ma...@apache.org>.
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.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org