[all][tc][Release Management] Improvements in project governance
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? 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.htm...
Comments inline. Michael On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski <skaplons@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.htm...
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
---- On Tue, 19 Apr 2022 11:01:48 -0500 Michael Johnson <johnsomor@gmail.com> wrote ----
Comments inline.
Michael
On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski <skaplons@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.htm...
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
Hi, At the very same time at the PTG we discussed this on the Release Management session [1] as well. To release deliverables without significant content is not ideal and this came up in previous discussions as well. On the other hand unfortunately this is the most feasible solution from release management team perspective especially because the team is quite small (new members are welcome! feel free to join the release management team! :)). To change to independent release model is an option for some cases, but not for every project. (It is less clear for consumers what version is/should be used for which series; Fixing problems that comes up in specific stable branches, is not possible; testing the deliverable against a specific stable branch constraints is not possiblel; etc.) See some other comments inline. [1] https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44 Előd On 2022. 04. 19. 18:01, Michael Johnson wrote:
Comments inline.
Michael
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
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
On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski<skaplons@redhat.com> wrote: project has been dropped/removed from OpenStack. That said, I think this is the point of the "independent" release classification. Yes, exactly as Michael says. 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. The release process catches libraries only (that had no merged change), so the number is not that huge, sending a mail seems to be a fair option.
(The process says: "Evaluate any libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model <https://releases.openstack.org/reference/release_models.html#openstack-related-libraries>. Note: client libraries (and other libraries strongly tied to another deliverable) should generally follow their parent deliverable release model, even if they did not have a lot of activity themselves).")
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.
There are a couple of good signals already for TC to catch inactive projects, like the generated patches that are not merged, for example: https://review.opendev.org/q/topic:reno-yoga+is:open https://review.opendev.org/q/topic:create-yoga+is:open https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open (Note that in the past not merged patches caused issues and discussing with the TC resulted a suggestion to force-merge them to avoid future issues)
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.
Yes, that's a fair point, too, maybe those broken deliverables should not be released at all. I'm not sure, but that might cause another issues for release management tooling, though... Besides, during our PTG session we came to the conclusion that we need another step in our process: * "propose DNM changes on every repository by RequirementsFreeze (5 weeks before final release) to check that tests are still passing with the current set of dependencies" Hopefully this will catch broken things well in advance.
[1]http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.htm...
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
Hi, On środa, 20 kwietnia 2022 13:19:10 CEST Előd Illés wrote:
Hi,
At the very same time at the PTG we discussed this on the Release Management session [1] as well. To release deliverables without significant content is not ideal and this came up in previous discussions as well. On the other hand unfortunately this is the most feasible solution from release management team perspective especially because the team is quite small (new members are welcome! feel free to join the release management team! :)).
To change to independent release model is an option for some cases, but not for every project. (It is less clear for consumers what version is/should be used for which series; Fixing problems that comes up in specific stable branches, is not possible; testing the deliverable against a specific stable branch constraints is not possiblel; etc.)
See some other comments inline.
[1] https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44
Előd
On 2022. 04. 19. 18:01, Michael Johnson wrote:
Comments inline.
Michael
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
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
On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski<skaplons@redhat.com> wrote: project has been dropped/removed from OpenStack. That said, I think this is the point of the "independent" release classification. Yes, exactly as Michael says. 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. The release process catches libraries only (that had no merged change), so the number is not that huge, sending a mail seems to be a fair option.
(The process says: "Evaluate any libraries that did not have any change merged over the cycle to see if it is time to transition them to the independent release model <https://releases.openstack.org/reference/release_models.html#openstack-related-libraries>. Note: client libraries (and other libraries strongly tied to another deliverable) should generally follow their parent deliverable release model, even if they did not have a lot of activity themselves).")
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.
There are a couple of good signals already for TC to catch inactive projects, like the generated patches that are not merged, for example:
https://review.opendev.org/q/topic:reno-yoga+is:open https://review.opendev.org/q/topic:create-yoga+is:open https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open
(Note that in the past not merged patches caused issues and discussing with the TC resulted a suggestion to force-merge them to avoid future issues)
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.
Yes, that's a fair point, too, maybe those broken deliverables should not be released at all. I'm not sure, but that might cause another issues for release management tooling, though...
Besides, during our PTG session we came to the conclusion that we need another step in our process: * "propose DNM changes on every repository by RequirementsFreeze (5 weeks before final release) to check that tests are still passing with the current set of dependencies" Hopefully this will catch broken things well in advance.
[1]http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.htm...
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
Thx for all inputs in that topic so far. Here is my summary and conclusion of what was said in that thread: * we shouldn't try automatically switch such "inactive" projects to the independent model, and we should continue bumping versions of such projects every cycle as it makes many things easier, * Release Management team will test projects about 5 weeks before final release - that may help us find broken projects which then can be discussed and eventually marked as deprecated to not release broken code finally, * To check potentially inactive projects TC can: * finish script https://review.opendev.org/c/openstack/governance/+/810037[1] and use stats generate by that script to periodically check projects' health, * check projects with no merged generated patches, like: https://review.opendev.org/q/topic:reno-yoga+is:open[2] https://review.opendev.org/q/topic:create-yoga+is:open[3] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open[4] Feel free to add/change anything in that summary if I missed or misunderstood anything there or if You have any idea about other improvements we can do in that area. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/governance/+/810037 [2] https://review.opendev.org/q/topic:reno-yoga+is:open [3] https://review.opendev.org/q/topic:create-yoga+is:open [4] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open
participants (4)
-
Előd Illés
-
Ghanshyam Mann
-
Michael Johnson
-
Slawek Kaplonski