I sent this to the other lists respecting Jeremy's decoupling:)

Francesco, Massimo, Jose,

We would love help from the other communities to continue creating the RPMS. We put a call out for volunteers over a year ago[0]. and while folks replied that they wanted to help or attended a meeting no one actually started helping. As a result, we added an important note to the bottom of the Epoxy release announcement[1] explaining that internal developers had moved on and we again said we needed help and to reach out if interested.

Amy

0 - https://lists.rdoproject.org/archives/list/dev@lists.rdoproject.org/thread/6X5DTJG5ZLKV5LZC5BVQY7ROQBV55XTV/
1 - https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/message/2O4U2QL5WLAMPW2B225MLYQEEYQCREP2/


On Fri, Mar 6, 2026 at 9:49 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
[I've dropped the cross-posting for other lists.]

On 2026-03-06 15:18:25 +0100 (+0100), Dmitriy Rabotyagov wrote:
> From my perspective, I am less concerned about the RDO itself, but
> more about rdo-deps. As, from what I know, rdo-deps sometimes are
> the only source of some dependencies, which are required for
> services.  Good example of that is liberasurecode, which is
> required by Swift, and can be hardly found elsewhere. I believe
> there are more examples of that, but this is what I can recall
> right away.
>
> Ideally, it would be nice to have some kind of SIG, or offload
> these packages to respective SIGs (like liberasurecode could be by
> Storage SIG potentially).
[...]

There's still a "Packaging SIG" listed as active at
https://governance.openstack.org/sigs/ with the description:

     To make OpenStack easier to update and consume by operators and
     provide tooling to package all OpenStack projects directly for
     (at first) all RPM based distributions.

According to governance, it's responsible for the following projects
in OpenDev:

     openstack/rpm-packaging
     openstack/rpm-packaging-tools
     openstack/pymod2pkg
     openstack/renderspec

Perhaps that would be a good place to coordinate (and revive if
necessary)?
--
Jeremy Stanley