Hey, I, as OSA PTL, have quite some concerns for approving further transition of branches to unmaintained state. There are multiple underlying reasons for that: 1. Currently our master branch is blocked by removal of stable/yoga, since `reno` is not ready to handle unmaintaned/* branches as well as eom-* tags. So all releasenotes jobs are failing right now. I've attempted to workaround the issue through the local reno config file [1], but this seems not working still. The only way I was able to pass releasenotes tox test, was by applying [2]. But even if it's proper approach and patch will be merged, reno still needs to be tagged and updated in upper-constraints, which can't be done as we're in a freeze right now. 2. I am not getting part regarding permissions to unmaintained/* branches that Brian was writing a while ago [3]. Sorry, I meant to answer that thread instead, but it was pushed slightly out of sight by other things. From what I recall during the original discussion of the unmaintained policy, core team of the project should be able to have access to such branches and take care of them if they want to. But now it was told not to do so. With that I'm really having a question, of who is intended to take care of reviewing, let's say OSA's unmaintained branches, even if there're outstanding patches being proposed by the community? I highly doubt that anybody, except cores and the community around the project care about that. And highly unlikely that openstack-unmaintained-core will take care of that. I also do see that some projects already created individual groups for themselves, which makes me even more confused about what projects should do. 3. We've started getting bugs [4] regarding Yoga transition to unmaintained status, since I assumed that we will have access to do some post-migration fixes to the branch, allowing users to continue using them if needed. But now Yoga is completely borked after transition with no clear way of fixing it, keeping 1 and 2 points in mind. Based on that I'm slightly reluctant to continue with the process until all points will be figured out. And what makes things even worse - is the timing for these activities, since we are not a huge team, and have our hands completely full especially close to the release, and figuring out how this new process should work was not part of the project plan as it was assumed as relatively simple change, which appears to be quite major one that is also blocking ongoing development. [1] https://review.opendev.org/c/openstack/openstack-ansible/+/908499 [2] https://review.opendev.org/c/openstack/reno/+/910547 [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... [4] https://bugs.launchpad.net/openstack-ansible/+bug/2055417 чт, 29 февр. 2024 г. в 23:30, Jay Faulkner <jay@gr-oss.io>:

Hi all,

If you are a PTL of a project, a release liason, or a person generally interested in older OpenStack branches, please make sure you take a look at the topic here: https://review.opendev.org/q/topic:%22vwx-unmaintained%22 and vote appropriately on projects you care about.

More information can be found in the commit message for the patches themselves.

A lot of folks have done work behind the scenes to enable this transition; please help us by doing your part and getting these reviews done in a timely manner is one way we can show gratitude to the releases team and others who have worked to make this transition possible.

Thanks, Jay Faulkner OpenStack TC Chair