[all][stable] Ocata - End of Life
Hi, Sorry, this will be long :) as there are 3 topics around old stable branches and 'End of Life'. 1. Deletion of ocata-eol tagged branches With the introduction of Extended Maintenance process [1][2] some cycles ago, the 'End of Life' (EOL) process also changed: * branches were no longer EOL tagged and "mass-deleted" at the end of maintenance phase * EOL'ing became a project decision * if a project decides to cease maintenance of a branch that is in Extended Maintenance, then they can tag their branch with $series-eol However, the EOL-tagging process was not automated or redefined process-wise, so that meant the branches that were tagged as EOL were not deleted. Now (after some changing in tooling) Release Management team finally will start to delete EOL-tagged branches. In this mail I'm sending a *WARNING* to consumers of old stable branches, especially *ocata*, as we will start deleting the *ocata-eol* tagged branches in a *week*. (And also newer *-eol branches later on) 2. Ocata branch Beyond the 1st topic we must clarify the future of Ocata stable branch in general: tempest jobs became broken about ~ a year ago. That means that projects had two ways forward: a. drop tempest testing to unblock gate b. simply don't support ocata branch anymore As far as I see the latter one happened and stable/ocata became unmaintained probably for every projects. So my questions are regarding this: * Is any project still using/maintaining their stable/ocata branch? * If not: can Release Team initiate a mass-EOL-tagging of stable/ocata? 3. The 'next' old stable branches Some projects still support their Pike, Queens and Rocky branches. These branches use Xenial and py2.7 and both are out of support. This results broken gates time to time. Especially nowadays. These issues suggest that these branches are closer and closer to being unmaintained. So I call the attention of interested parties, who are for example still consuming these stable branches and using them downstream to put effort on maintaining the branches and their CI/gates. It is a good practice for stable maintainers to check if there are failures in their projects' periodic-stable jobs [3], as those are good indicators of the health of their stable branches. And if there are, then try to fix it as soon as possible. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.h... [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenan... [3] http://lists.openstack.org/pipermail/openstack-stable-maint/2021-April/date.... Thanks, Előd
Hi, some update here: * Last week I've tried the new tooling (gerrit ACLs) and deleted cinder's ocata-eol tagged stable/ocata branch and it worked as it should so now I'll continue to *delete* all other ocata-eol tagged branches. * The next phase will be the deletion of *pike-eol* tagged branches. So this is a *warning* again for downstream and upstream CI maintainers. Thanks, Előd On 2021. 04. 20. 21:31, Előd Illés wrote:
Hi,
Sorry, this will be long :) as there are 3 topics around old stable branches and 'End of Life'.
1. Deletion of ocata-eol tagged branches
With the introduction of Extended Maintenance process [1][2] some cycles ago, the 'End of Life' (EOL) process also changed: * branches were no longer EOL tagged and "mass-deleted" at the end of maintenance phase * EOL'ing became a project decision * if a project decides to cease maintenance of a branch that is in Extended Maintenance, then they can tag their branch with $series-eol
However, the EOL-tagging process was not automated or redefined process-wise, so that meant the branches that were tagged as EOL were not deleted. Now (after some changing in tooling) Release Management team finally will start to delete EOL-tagged branches.
In this mail I'm sending a *WARNING* to consumers of old stable branches, especially *ocata*, as we will start deleting the *ocata-eol* tagged branches in a *week*. (And also newer *-eol branches later on)
2. Ocata branch
Beyond the 1st topic we must clarify the future of Ocata stable branch in general: tempest jobs became broken about ~ a year ago. That means that projects had two ways forward:
a. drop tempest testing to unblock gate b. simply don't support ocata branch anymore
As far as I see the latter one happened and stable/ocata became unmaintained probably for every projects.
So my questions are regarding this: * Is any project still using/maintaining their stable/ocata branch? * If not: can Release Team initiate a mass-EOL-tagging of stable/ocata?
3. The 'next' old stable branches
Some projects still support their Pike, Queens and Rocky branches. These branches use Xenial and py2.7 and both are out of support. This results broken gates time to time. Especially nowadays. These issues suggest that these branches are closer and closer to being unmaintained. So I call the attention of interested parties, who are for example still consuming these stable branches and using them downstream to put effort on maintaining the branches and their CI/gates.
It is a good practice for stable maintainers to check if there are failures in their projects' periodic-stable jobs [3], as those are good indicators of the health of their stable branches. And if there are, then try to fix it as soon as possible.
[1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.h... [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenan... [3] http://lists.openstack.org/pipermail/openstack-stable-maint/2021-April/date....
Thanks,
Előd
Hi, As I wrote in my previous mails, Ocata is not really maintained and gates are borken. So now the Ocata-EOL transitioning patches [1] have been generated for the rest of the projects that were not transitioned yet. Those teams who don't want to / cannot maintain their stable/ocata branch anymore: * please review the transition patch and +1 it and * clean up the unnecessary zuul jobs If a patch is approved, the last patch on stable/ocata will be tagged with *ocata-eol* tag. This can be checked out after stable/ocata is deleted. [1] https://review.opendev.org/q/topic:ocata-eol Thanks, Előd On 2021. 04. 20. 21:31, Előd Illés wrote:
Hi,
Sorry, this will be long :) as there are 3 topics around old stable branches and 'End of Life'.
1. Deletion of ocata-eol tagged branches
With the introduction of Extended Maintenance process [1][2] some cycles ago, the 'End of Life' (EOL) process also changed: * branches were no longer EOL tagged and "mass-deleted" at the end of maintenance phase * EOL'ing became a project decision * if a project decides to cease maintenance of a branch that is in Extended Maintenance, then they can tag their branch with $series-eol
However, the EOL-tagging process was not automated or redefined process-wise, so that meant the branches that were tagged as EOL were not deleted. Now (after some changing in tooling) Release Management team finally will start to delete EOL-tagged branches.
In this mail I'm sending a *WARNING* to consumers of old stable branches, especially *ocata*, as we will start deleting the *ocata-eol* tagged branches in a *week*. (And also newer *-eol branches later on)
2. Ocata branch
Beyond the 1st topic we must clarify the future of Ocata stable branch in general: tempest jobs became broken about ~ a year ago. That means that projects had two ways forward:
a. drop tempest testing to unblock gate b. simply don't support ocata branch anymore
As far as I see the latter one happened and stable/ocata became unmaintained probably for every projects.
So my questions are regarding this: * Is any project still using/maintaining their stable/ocata branch? * If not: can Release Team initiate a mass-EOL-tagging of stable/ocata?
3. The 'next' old stable branches
Some projects still support their Pike, Queens and Rocky branches. These branches use Xenial and py2.7 and both are out of support. This results broken gates time to time. Especially nowadays. These issues suggest that these branches are closer and closer to being unmaintained. So I call the attention of interested parties, who are for example still consuming these stable branches and using them downstream to put effort on maintaining the branches and their CI/gates.
It is a good practice for stable maintainers to check if there are failures in their projects' periodic-stable jobs [3], as those are good indicators of the health of their stable branches. And if there are, then try to fix it as soon as possible.
[1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.h... [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintenan... [3] http://lists.openstack.org/pipermail/openstack-stable-maint/2021-April/date....
Thanks,
Előd
participants (1)
-
Előd Illés