[Idea] Better Syncing with Spins and Labs Maintainers #12988

New issue

Open

opened 2025-10-03 09:15:57 +00:00 by amoloney · 5 comments

amoloney commented

2025-10-03 09:15:57 +00:00

Hello Releng team,

This release has uncovered a little gap in the spins and labs keepalive process. There doesnt seem to be a shared list or something of spin and lab maintainers between releng and pgm. The current process has pgm opening keepalive tickets and tagging maintainers, but there is no steps to follow then to both confirm the correct maintainers are listed in the releng file, or who should update any changes to spin or lab maintainership and make sure this info gets into the releng file.

My idea:
Add a step into the ticket template in the pgm sop[1] for the keepalive process, prompting spin and lab maintainers to file a PR against the releng files[2],[3] if the spin or lab maintainership has changed. I am already including a prompt in the pagure ticket requesting maintainers who do not wish to keep their spin or lab alive for Fxx release to file a websites and a releng ticket also. See example of comp neuro spin[4].

What are your thoughts? Would this help at all to keep things as in sync as much as possible?
I will also make sure the emails on reminders for the keepalive process gets sent more regularly too. That was a complete oversight on my part and has added to the confusion for sure :(

[1] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/
[2] https://pagure.io/fedora-kickstarts/blob/main/f/maintainers.toml
[3] https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/maintainers.toml
[4] https://pagure.io/fedora-pgm/schedule/issue/207

Hello Releng team, This release has uncovered a little gap in the spins and labs keepalive process. There doesnt seem to be a shared list or something of spin and lab maintainers between releng and pgm. The current process has pgm opening keepalive tickets and tagging maintainers, but there is no steps to follow then to both confirm the correct maintainers are listed in the releng file, or who should update any changes to spin or lab maintainership and make sure this info gets into the releng file. My idea: Add a step into the ticket template in the pgm sop[1] for the keepalive process, prompting spin and lab maintainers to file a PR against the releng files[2],[3] if the spin or lab maintainership has changed. I am already including a prompt in the pagure ticket requesting maintainers who do not wish to keep their spin or lab alive for Fxx release to file a websites and a releng ticket also. See example of comp neuro spin[4]. What are your thoughts? Would this help at all to keep things as in sync as much as possible? I will also make sure the emails on reminders for the keepalive process gets sent more regularly too. That was a complete oversight on my part and has added to the confusion for sure :( [1] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/ [2] https://pagure.io/fedora-kickstarts/blob/main/f/maintainers.toml [3] https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/maintainers.toml [4] https://pagure.io/fedora-pgm/schedule/issue/207

jnsamyak commented

2025-10-03 09:27:36 +00:00

Owner

Metadata Update from @jnsamyak:

Issue assigned to jnsamyak

**Metadata Update from @jnsamyak**: - Issue assigned to jnsamyak

james commented

2025-10-06 19:12:22 +00:00

Member

Metadata Update from @james:

Issue tagged with: low-trouble, medium-gain

**Metadata Update from @james**: - Issue tagged with: low-trouble, medium-gain

amoloney commented

2025-10-15 11:04:33 +00:00

Author

I've also updated the PgM SOP [4] with these instructions and will send an email to the lists before I leave next week updating folks of these changes to the keepalive process. The page hasn't rebuilt yet, but it should be updated later today. To be honest, I don't think they're actually changes, but rather steps that should have always been taken but have been overlooked in the last few releases. So this is really just making things more obvious for everyone :)

The only ask on releng is to let me know if there's any feedback, and if the files you use change at any time for the spins and labs records, to file an issue in the schedule repo so I can update the template. Feel free to close this ticket if everything seems ok to you folks.

Thanks!

[1] https://pagure.io/fedora-pgm/schedule/new_issue
[2] https://pagure.io/fedora-kickstarts/blob/main/f/maintainers.toml
[3] https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/maintainers.toml
[4] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/

Just a little update on this - I have created a template for the spins and labs keepalive request in the pgm_schedule repo[1]. It requests the maintainer file a PR against the releng files [2] & [3] if there is a change in maintainer-ship of the spin or lab, and also gives instructions on what to do if they want to not keep the spin or lab alive in the Fedora release. I've also updated the PgM SOP [4] with these instructions and will send an email to the lists before I leave next week updating folks of these changes to the keepalive process. The page hasn't rebuilt yet, but it should be updated later today. To be honest, I don't think they're actually changes, but rather steps that should have always been taken but have been overlooked in the last few releases. So this is really just making things more obvious for everyone :) The only ask on releng is to let me know if there's any feedback, and if the files you use change at any time for the spins and labs records, to file an issue in the schedule repo so I can update the template. Feel free to close this ticket if everything seems ok to you folks. Thanks! [1] https://pagure.io/fedora-pgm/schedule/new_issue [2] https://pagure.io/fedora-kickstarts/blob/main/f/maintainers.toml [3] https://pagure.io/fedora-kiwi-descriptions/blob/rawhide/f/maintainers.toml [4] https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/spins-keepalive/

jnsamyak commented

2025-11-03 12:40:25 +00:00

Owner

Metadata Update from @jnsamyak: