Open Stack

 ---- On Tue, 19 Apr 2022 11:01:48 -0500 Michael Johnson <johnsomor at gmail.com> wrote ----
 > 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.

Yeah, we can do that but I agree on moving such projects to the 'independent' release model.

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

Even we started one script to collect such stats per project with their gate job status,
its under review - https://review.opendev.org/c/openstack/governance/+/810037

 > 
 > > 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. Indeed, if no one is there to fix the code/test of such projects I am not sure who will
care about its release too. So I 100% agree with not repeating the steps of fixing and releasing 
them as we did in Yoga.

-gmann

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