stephenfin | fungi: When you're about, could I ask you to add gtema and I to ~python-openstackclient-drivers and ~python-openstackclient-bugs on launchpad and to delete ~python-openstackclient-core (or add me so I can do it)? | 11:20 |
---|---|---|
stephenfin | It seems projects like nova use -drivers for core team with e.g. blueprint permissions, and -bugs for bug triaging | 11:21 |
stephenfin | e.g. the bug supervisor for https://bugs.launchpad.net/nova is ~nova-bugs, while the driver of the project is ~nova-drivers. We should probably replicate that format? | 11:22 |
frickler | stephenfin: done. iirc fungi had an idea of nesting these groups to make managing them easier, since the delta between them should be pretty small these days | 12:02 |
frickler | it would likely also be good to do some cleanup of no longer active members | 12:03 |
stephenfin | frickler: Sure. I think I need to be an administrator for that though | 12:04 |
stephenfin | and I suspect only an admin of ~openstack-admins can do that? | 12:05 |
stephenfin | since that's the owner of ~python-openstackclient-bugs | 12:05 |
frickler | stephenfin: I did set you and artem as admins now, maybe that will be enough? otherwise just let me know who should get removed | 12:08 |
fungi | admin within those groups should suffice, yes | 13:36 |
fungi | the only time you need group maintainer intervention is when no group admins are around | 13:37 |
jamespage | fungi: hey - please could we get https://review.opendev.org/c/openstack/project-config/+/900167 merged? | 15:45 |
*** ykarel is now known as ykarel|away | 15:51 | |
fungi | jamespage: sure, i was hoping frickler would have time to revisit the earlier comment that got resolved on it, but i agree it's been sitting a while so i'll go ahead and single-core approve | 16:16 |
opendevreview | Merged openstack/project-config master: Create mono repo for sunbeam charms https://review.opendev.org/c/openstack/project-config/+/900167 | 16:23 |
fungi | jamespage: that ^ should exist now | 16:36 |
jamespage | fungi: great thanks! | 16:36 |
rosmaita | fungi: what's the procedure for creating $PROJECT-unmaintained-core groups in Gerrit? | 17:16 |
frickler | rosmaita: I think we'll first need acls that define their use for the unmaintained branches, then the referenced groups get created automatically | 18:35 |
frickler | then as the last step some infra-root will have to seed them with a person that will then manage other members | 18:37 |
rosmaita | frickler: thanks ... looking at for example gerrit/acls/openstack/cinder.config , looks like we will need to add a new access section for refs/heads/unmaintained/* | 18:43 |
rosmaita | and then if we just mention a group in there, it gets created automatically? | 18:44 |
frickler | rosmaita: yes. I'm not sure though whether each project should do this change individually or whether someone can generate a mass change for all openstack projects. the latter would sure make life easier for the people that need to review and approve this. | 18:48 |
rosmaita | agree | 18:48 |
frickler | maybe also we can add tc-members or tc-chair as members of those groups, to relieve the maintainance work needed by the infra team | 18:49 |
frickler | jamespage: fungi: I was hoping for some feedback on the associated governance patch, it seems weird to me that there still patches open to add more individual repos, when according to my understanding those will be superceded by the mono repo | 18:55 |
jamespage | frickler: ah right I see the goverance changes for two new repositories are still open; the mono-repo switch was discussed at the vPTG and then some of the team have been able to focus on moving that idea forward this week as we have been in a single location for a Canonical event | 19:00 |
jamespage | you are correct that they will be superseeded by the mono-repo | 19:01 |
fungi | frickler: rosmaita: yeah, it's mainly a question of whether the groups should be self-owned (and then we set tc-members as "included" in the group and let them or other group members add people as they see fit) or whether tc-members wants to be the "owner" of those groups (so only they can add new people to them) | 19:14 |
rosmaita | fungi: thanks, i think i will make a list of open questions for this effort | 19:16 |
dansmith | we want to avoid tc members getting pinged for actual reviews I think, | 19:16 |
dansmith | so we probably need to make it clear that they're there to add people to the group, not to review patches right? | 19:16 |
fungi | dansmith: yeah, the main question is whether non-tc members of the group should have the ability (not necessarily authority) to add other people | 19:18 |
dansmith | oh I thought that was what was being suggested | 19:18 |
fungi | secondarily though, whether tc members should have +2/approval rights on those changes | 19:19 |
dansmith | I think that's okay if it helps spread the load out, I just think we need to make it clear that you shouldn't expect to ping a TC member for a +2 "just this one time for this small patch" | 19:19 |
dansmith | oh, if we can separate those abilities, that'd be great I tink | 19:19 |
dansmith | make it clear that we're not there to +2 things ... because we can't :) | 19:19 |
fungi | yeah, it comes down to whether the group is self-owned (and includes the tc, so tc members or any other group member have access to add more group members) or tc-owned (so only the tc can add members to the group) | 19:20 |
fungi | we could also have yet another group for people delegated authority to add people to the unmaintained reviewer groups | 19:21 |
dansmith | idk, self-managed (plus tc to handle the zero members case) makes sense to me | 19:25 |
fungi | cool, i have no real recommendation other than to lay out the options so the tc can decide how they would like it to work | 19:27 |
gmann | yeah, TC can handle when there is no one to add members in any group like infra admin do in today case. other than that those should be self managed | 20:11 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!