Re: [sdk][congress][octavia][designate][magnum][senlin][swift] Adding project-specific cores to SDK
Any chance of reusing the “PTL ack” bot that has recently appeared in the releases repo? But as a “SME ack” that would recognize anyone from $project’s core team? (How does the releases bot know which project the patch is for? Might have to be a bit fuzzy on that logic for SDK/OSC.) Then the team could adopt a policy of single core approval if the patch has this SME +1, and no real danger of “abuse”. Eric Fried
Hi, I’m fine with adding those new people to the core team. As Monty said, I’m not doing too many reviews in sdk project but I’m trying to always check neutron related changes and I think that having such expert for other projects would be good too.
On 6 Mar 2020, at 04:40, Eric Fried <openstack@fried.cc> wrote:
Any chance of reusing the “PTL ack” bot that has recently appeared in the releases repo? But as a “SME ack” that would recognize anyone from $project’s core team? (How does the releases bot know which project the patch is for? Might have to be a bit fuzzy on that logic for SDK/OSC.)
That also seems like potential solution but as changes in this repo are a bit differently then in e.g. releases repo how bot will exactly know which PTL should approve the patch? It may be much harder to do here than in releases repo, no?
Then the team could adopt a policy of single core approval if the patch has this SME +1, and no real danger of “abuse”.
Eric Fried
— Slawek Kaplonski Senior software engineer Red Hat
That also seems like potential solution but as changes in this repo are a bit differently then in e.g. releases repo how bot will exactly know which PTL should approve the patch? It may be much harder to do here than in releases repo, no?
Yeah, I agree, which is why I asked how the releases repo does it. I can envision the bot knowing which packages/files pertain to a given project and doing the mapping that way. And like if multiple projects' files are touched, the bot doesn't register the SME+1 until there's a +1 from each project. But yeah, this is getting a bit heavy weight. Then again, it allays diablo_rojo's concern about SMEs' ability to +W, and johnsom's concern about impacting morale by singling out individuals. Anyway, just a thought. efried_gone .
On Mar 6, 2020, at 1:31 AM, Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
I’m fine with adding those new people to the core team. As Monty said, I’m not doing too many reviews in sdk project but I’m trying to always check neutron related changes and I think that having such expert for other projects would be good too.
On 6 Mar 2020, at 04:40, Eric Fried <openstack@fried.cc> wrote:
Any chance of reusing the “PTL ack” bot that has recently appeared in the releases repo? But as a “SME ack” that would recognize anyone from $project’s core team? (How does the releases bot know which project the patch is for? Might have to be a bit fuzzy on that logic for SDK/OSC.)
That also seems like potential solution but as changes in this repo are a bit differently then in e.g. releases repo how bot will exactly know which PTL should approve the patch? It may be much harder to do here than in releases repo, no
I agree with Slawek - I like this idea but I think it *is* a harder one to accomplish. Also, sometimes patches are straightforward enough that we don’t really need a service-specific ack from … especially when the service has good and clear API documentation. I think I’m leaning towards liking Michael’s suggestion a bit better as a next step - having the teams suggest a person, liaison-style - mostly because it’s easy. But for now, even with that - and even with my flub of completely blanking on Michael, let’s see how playing it by ear goes before we add more process.
Then the team could adopt a policy of single core approval if the patch has this SME +1, and no real danger of “abuse”.
Eric Fried
— Slawek Kaplonski Senior software engineer Red Hat
On 2020-03-05 21:40:54 -0600 (-0600), Eric Fried wrote:
Any chance of reusing the “PTL ack” bot that has recently appeared in the releases repo? But as a “SME ack” that would recognize anyone from $project’s core team? (How does the releases bot know which project the patch is for? Might have to be a bit fuzzy on that logic for SDK/OSC.) [...]
The openstack/releases repository has its critical data organized by OpenStack governance project team deliverable, and there's a Zuul job which gets triggered on every review comment which looks to see if the Gerrit account leaving the comment maps through https://opendev.org/openstack/releases/src/branch/master/data/release_liaiso... and https://opendev.org/openstack/governance/src/branch/master/reference/project... to match the reviewer to the deliverable(s) covered by the proposed change. To do something similar for the OSC/SDK repos, you'd need 1. a means of programmatically identifying the relevant project team for any proposed change, and 2. some list of unique Gerrit account identifiers (most likely E-mail addresses) of the people whose reviews are relevant for them. -- Jeremy Stanley
participants (4)
-
Eric Fried
-
Jeremy Stanley
-
Monty Taylor
-
Slawek Kaplonski