Friday, 2023-11-10

stephenfinfungi: 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
stephenfinIt seems projects like nova use -drivers for core team with e.g. blueprint permissions, and -bugs for bug triaging11:21
stephenfine.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
fricklerstephenfin: 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 days12:02
fricklerit would likely also be good to do some cleanup of no longer active members12:03
stephenfinfrickler: Sure. I think I need to be an administrator for that though12:04
stephenfinand I suspect only an admin of ~openstack-admins can do that?12:05
stephenfinsince that's the owner of ~python-openstackclient-bugs12:05
fricklerstephenfin: I did set you and artem as admins now, maybe that will be enough? otherwise just let me know who should get removed12:08
fungiadmin within those groups should suffice, yes13:36
fungithe only time you need group maintainer intervention is when no group admins are around13:37
jamespagefungi: hey - please could we get https://review.opendev.org/c/openstack/project-config/+/900167 merged? 15:45
*** ykarel is now known as ykarel|away15:51
fungijamespage: 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 approve16:16
opendevreviewMerged openstack/project-config master: Create mono repo for sunbeam charms  https://review.opendev.org/c/openstack/project-config/+/90016716:23
fungijamespage: that ^ should exist now16:36
jamespagefungi: great thanks!16:36
rosmaitafungi: what's the procedure for creating $PROJECT-unmaintained-core groups in Gerrit?17:16
fricklerrosmaita: I think we'll first need acls that define their use for the unmaintained branches, then the referenced groups get created automatically18:35
fricklerthen as the last step some infra-root will have to seed them with a person that will then manage other members18:37
rosmaitafrickler: 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
rosmaitaand then if we just mention a group in there, it gets created automatically?18:44
fricklerrosmaita: 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
rosmaitaagree18:48
fricklermaybe also we can add tc-members or tc-chair as members of those groups, to relieve the maintainance work needed by the infra team18:49
fricklerjamespage: 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 repo18:55
jamespagefrickler: 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 event19:00
jamespageyou are correct that they will be superseeded by the mono-repo19:01
fungifrickler: 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
rosmaitafungi: thanks, i think i will make a list of open questions for this effort19:16
dansmithwe want to avoid tc members getting pinged for actual reviews I think,19:16
dansmithso we probably need to make it clear that they're there to add people to the group, not to review patches right?19:16
fungidansmith: yeah, the main question is whether non-tc members of the group should have the ability (not necessarily authority) to add other people19:18
dansmithoh I thought that was what was being suggested19:18
fungisecondarily though, whether tc members should have +2/approval rights on those changes19:19
dansmithI 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
dansmithoh, if we can separate those abilities, that'd be great I tink19:19
dansmithmake it clear that we're not there to +2 things ... because we can't :)19:19
fungiyeah, 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
fungiwe could also have yet another group for people delegated authority to add people to the unmaintained reviewer groups19:21
dansmithidk, self-managed (plus tc to handle the zero members case) makes sense to me19:25
fungicool, i have no real recommendation other than to lay out the options so the tc can decide how they would like it to work19:27
gmannyeah, 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 managed20:11

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!