[all][stable] Ocata - End of Life

Előd Illés elod.illes at est.tech
Tue Apr 20 19:31:03 UTC 2021


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.




More information about the openstack-discuss mailing list