[all][tc][Release Management] Improvements in project governance

Slawek Kaplonski skaplons at redhat.com
Tue Apr 19 13:26:12 UTC 2022


During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance.
One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle.
Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too?
If yes, should we then automatically propose change of the release model to the "independent" maybe?
What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team.

Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all?

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html[1]

Slawek Kaplonski
Principal Software Engineer
Red Hat

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220419/f59cd320/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220419/f59cd320/attachment.sig>

More information about the openstack-discuss mailing list