Hi, If this topic has been discussed many times already then someone please say so and we can leave it alone. As kolla PTL and ironic release liaison I've proposed a number of release patches recently. Generally the release team is good at churning through these, but sometimes patches can hang around for a while. Usually a ping on IRC will get things moving again within a day or so (thanks in particular to Sean who has been very responsive). Related to the recent discussion about decentralising stable branch maintenance, should we do this for releases too? To be clear, I'm proposing giving project teams more control over their own releases. I brought this up in IRC recently and there was a brief discussion. I suggested that releases are hard to undo, and Monty corrected me by saying they are impossible to undo. Still, if teams (or a subset of their members) had more ownership of their releases, they would become more familiar with the process, and the risk would be reduced. I'm not suggesting that release team should be disbanded - there is clearly work to do to maintain the tooling, determine and communicate the schedule, and more. But there's a lot of toil involved in checking and approving patches to the releases repo, and it's done by some of our most senior, busy colleagues. There are a number of checks that are performed automatically by the tooling and used to gate merges. I have a few questions for the release team about these reviews. * What manual checks do you do beyond those that are currently automated? * Could the above checks be automated? * What issues have you caught that were not caught by CI jobs? Hopefully I haven't offended anyone here. There's often more involved with these things than you first suspect. Cheers, Mark