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

Michael Johnson johnsomor at gmail.com
Tue Apr 19 16:01:48 UTC 2022


Comments inline.

Michael

On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski <skaplons at redhat.com> wrote:
>
> Hi,
>
>
> 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?

In the past this has created confusion in the community about if a
project has been dropped/removed from OpenStack. That said, I think
this is the point of the "independent" release classification.

> If yes, should we then automatically propose change of the release model to the "independent" maybe?

Personally, I would prefer to send an email to the discuss list
proposing the switch to independent. Patches can sometimes get merged
before everyone gets to give input. Especially since the patch would
be proposed in the "releases" project and may not be on the team's
dashboards.

> 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.

It seems like this would be a straight forward script to write given
we already have tools to capture the list of changes included in a
given release.

> 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?

In the past we have simply not released projects that are broken and
don't have people actively working on fixing them. It has been a
signal to the community that if they value the project they need to
contribute to it.

> [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html
>
>
> --
>
> Slawek Kaplonski
>
> Principal Software Engineer
>
> Red Hat



More information about the openstack-discuss mailing list