On Fri, May 26, 2017 at 6:10 PM Sam Ruby <ru...@intertwingly.net> wrote:
> TL;DR: podling membership lists are being consolidated to LDAP, podling > mentor lists remain in podlings.xml; the whimsy roster tool is being > updated to become a one-stop-shop that can be used to update everything. > > For the impatient, a link: > > https://whimsy.apache.org/roster/ppmc/trafodion > > Feedback welcome on the proposal below. Fair warning: I'll treat any > lack of input as lazy consensus. :-) > > --- Background --- > > In the past, we've had a number of ad-hoc ways of keeping track of who > is on on a PPMC, and made policies based on the difficultly involved in > keeping track of memberships. > > For example, JIRA requests to add svn access control lists to PPMCs > (even ones that use only git!) in order to have the lists be reflected > on the phonebook app. And to have every committer on the IPMC have > update access to all podlings. > > Now we are moving towards making PPMCs more like PMCs, where the key > differences are intentional - for example the addition of mentors and > not being listed in commitee-info.txt. > > Gitbox has been updated, our ponymail installation has been updated, our > svn server will be updated soon. Other services will be updated as well. > > What about regular git-wip-us? > --- Roster tool --- > > Now to the primary subject of this email: the roster tool. > > If you go to the link above, you will see a list of mentors and a list > of PPMC members. By early next week, a separate list of committers will > be shown when that list happens to be different than the list of PPMC > members. > It may be better to link to https://whimsy.apache.org/roster/ppmc/ rather than a specific project. > > Adding a new committer, PPMC member, or mentors should be a matter a few > mouse clicks and selecting the name. LDAP and/or podlings.xml will be > updated on your behalf. > > FWIW, I just tried adding you as a mentor to a podling, it failed with a 500 ISE. > If you treat each of those lists (committer, PPMC member, and mentors) > as separate, there are 2^3 possible combinations. If you subtract the > current state, there are still 7 possible new states for every change. > From a coding perspective, that's manageable, but having that many > options makes the tool harder to use, and increases the possibility of > human error. > > For that reason, I'd like to make a simplifying assumption: that all > mentors are PPMC members, and all PPMC members are committers. > > Fair assumption. > Note: in the rare cases where the various lists are inconsistent, > additional options will be presented. The link above has examples of > mentors who are currently not members of the PPMC. > > --- Access control --- > > A final topic is access control. Public views of the underlying data > will be made possible through the phonebook application. Any committer > will be able to see the roster tool. The key question left is updating. > > Specifically: > > 1) Who should be able to add/remove mentors? My initial assumption is > any IPMC member. > > Agreed. > 2) Who is eligible to be added as a mentor? Again, my assumption is any > IPMC member. > Agreed. > > 3) Who should be able to add/remove PPMC members? My assumption is any > member of the PPMC. > Disagree. The PPMC may add a member if there is a check that a NOTICE was sent and received >= 72 hours ago. If that check is not in place I feel it is up to mentors only. > > 4) Who is eligible to be added as a PPMC member? My assumption is any > ASF committer. > Agreed. > > 5) Who should be able to add/remove PPMC committers? Again, my > assumption is any member of the PPMC. > The term "PPMC committers" is hard to follow. "podling committer" may make more sense, or simply committer. There may be cases that an IPMC member needs to add a committer. In this case, they can just add themselves as mentor to do it. Its a little bit of a loophole. > > 6) Who is eligible to be added as a PPMC committer? Again, my > assumption is any ASF committer. > Most of the time committers to a podling are new to the ASF. Can the processes that secretary runs include adding to a podling? > > Feedback on these assumptions welcome. Any change to mentors and/or > PPMC members will result in a notification to the private incubator > mailing list. Any change to PPMC members and committers will result in > a notification to the infrastructure team. Any change at all will > result in a notification to the private mailing PPMC mailing list. > I'm not sure why infra is getting notified but IPMC is not notified, about committers. Does infra have a requirement to be notified? > > Related: https://issues.apache.org/jira/browse/WHIMSY-90; which might > not be practical as stated due to difference in access control between > the various lists. Even if that turns out to be the case, a tool can be > created to identify differences and enable bulk updating. > > I'm not sure how that's relevant to this email, maybe you should keep discussions around the design and development of whimsy on the dev@whimsical list, or just reply to the JIRA and the reporter will follow up. FWIW, until we fix all permissions to be based on podling, we need podling committers added to incubator. In addition, the incubator website is meant to be maintained by any incubator committer so that sort of assumes they're in the incubator group. If the issue is auto removal, I'll point out that's something you raised and wasn't a requirement going in (and in fact, people stay on incubator even after their podling has graduated). > - Sam Ruby > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
