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 <johndam...@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-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > > > > > > > > -- > > Stian Soiland-Reyes > > http://orcid.org/0000-0001-9842-9718 > > > > --------------------------------------------------------------------- > > 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 > >
