[charms] Team Delegation proposal

Alex Kavanagh alex.kavanagh at canonical.com
Mon Aug 8 20:14:23 UTC 2022


Hi Chris

On Thu, 28 Jul 2022 at 21:46, Chris MacNaughton <
chris.macnaughton at canonical.com> wrote:

> Hello All,
>
> <tl;dr>
> I would like to propose some new ACLs in Gerrit for the openstack-charms
> project:
>
> - openstack-core-charms
> - ceph-charms
> - network-charms
> - stable-maintenance
> </tl;dr>
>

I think the names need to be tweaked slightly:

- charms-openstack
- charms-ceph
- charms-ovn
- charms-maintenance

This is to keep it inline/similar to the other charms-* groups.

Back to the email proper:


>
> With an increasing focus split among the openstack-charmers team, I'm
> observing that people are focused on more specific subsets of the charms,
> and would like to propose that new ACLs are created to allow us to
> recognize that officially. I've chosen the breakdown above as it aligns
> neatly with where the focus lines are at this point, letting developers
> work on their specific focus areas.
>

Whilst this is a reasonable idea, I'll admit to being slightly worried that
it will solidify the lines between the teams; but perhaps that's what's
going to happen anway?


>
> This proposal would not reduce permissions for anybody who is currently a
> core on the openstack-charms project and, in fact, future subteam core
> members could aspire to full openstack-charmers core as well. Ideally, this
> approach will let us escalate developers to "core" developers for the
> subteam(s) where they have demonstrated the expertise we expect in a
> core-charmer. It also allows a more gradual escalation to being a core in
> the openstack-charms project, making it a progression rather than a single
> destination.
>

Not a bad idea.


>
> As a related addition, I'm appending to this proposal the creation of a
> stable-maintenance ACL which would allow members to manage backports
> without a full core-charmer grant.
>

I guess with this one we'd have to be careful when assigning.  Landing
things in stable releases is basically a measure of how well we, as a team,
manage regressions and how much work that creates in terms of managing our
very large stable charm set.  I'd be keen to hold this one back if we can.

So why trial it with `charms-ceph`?

Cheers
Alex

---



> ---
> Chris MacNaughton
>


-- 
Alex Kavanagh - Software Engineer
OpenStack Engineering - Data Centre Development - Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220808/67059dda/attachment-0001.htm>


More information about the openstack-discuss mailing list