osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[release] decentralising release approvals


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191219/8b707ad2/attachment.html>