The release page says Ocata is planned to go into extended maintenance
mode on Aug 27 [1]. There really isn't much to this except it means we
don't do releases for Ocata anymore [2]. There is a caveat that project
teams that do not wish to maintain stable/ocata after this point can
immediately end of life the branch for their project [3]. We can still
run CI using tags, e.g. if keystone goes ocata-eol, devstack on
stable/ocata can still continue to install from stable/ocata for nova
and the ocata-eol tag for keystone. Having said that, if there is no
undue burden on the project team keeping the lights on for stable/ocata,
I would recommend not tagging the stable/ocata branch end of life at
this point.
So, questions that need answering are:
1. Should we cut a final release for projects with stable/ocata branches
before going into extended maintenance mode? I tend to think "yes" to
flush the queue of backports. In fact, [3] doesn't mention it, but the
resolution said we'd tag the branch [4] to indicate it has entered the
EM phase.
2. Are there any projects that would want to skip EM and go directly to
EOL (yes this feels like a Monopoly question)?
[1] https://releases.openstack.org/
[2]
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3]
https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[4]
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
mode on Aug 27 [1]. There really isn't much to this except it means we
don't do releases for Ocata anymore [2]. There is a caveat that project
teams that do not wish to maintain stable/ocata after this point can
immediately end of life the branch for their project [3]. We can still
run CI using tags, e.g. if keystone goes ocata-eol, devstack on
stable/ocata can still continue to install from stable/ocata for nova
and the ocata-eol tag for keystone. Having said that, if there is no
undue burden on the project team keeping the lights on for stable/ocata,
I would recommend not tagging the stable/ocata branch end of life at
this point.
So, questions that need answering are:
1. Should we cut a final release for projects with stable/ocata branches
before going into extended maintenance mode? I tend to think "yes" to
flush the queue of backports. In fact, [3] doesn't mention it, but the
resolution said we'd tag the branch [4] to indicate it has entered the
EM phase.
2. Are there any projects that would want to skip EM and go directly to
EOL (yes this feels like a Monopoly question)?
[1] https://releases.openstack.org/
[2]
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3]
https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[4]
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
--
Thanks,
Matt
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators