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 <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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
