<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 9, 2022 at 11:36 PM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
As you probably already know from gmann's reporting, the TC recently<br>
passed a resolution[1] regarding the release cadence. This, in response<br>
to some discussion around moving to different release cycle lengths,<br>
becomes mostly a change regarding our deprecation procedures, as well as<br>
a call to support the ability to skip certain releases (designated<br>
"tock" releases) while sticking on a yearly cycle (designated "tick"<br>
releases).<br>
<br>
In support of the goal of moving to this new cadence for the AA release<br>
(i.e. the yet unnamed release to come after Zed), I have introduced[2] a<br>
new grenade-skip-level job, which tests skipping "tock" releases and<br>
going straight from one tick to the following. We intend this to be a<br>
voting job in AA, making sure it works from Yoga->AA. Right now it tests<br>
Wallaby->Yoga for informational purposes. We would recommend projects<br>
enable that as voting, or define their own job to do similar testing as<br>
soon as possible. Manila has already started[3] this. Note that existing<br>
grenade testing between each adjacent release remains unchanged in this<br>
scheme.<br></blockquote><div><br></div><div>I don't think we have cycles in Ironic to do that. Unless somebody who really cares wants to not just do the work on setting up such jobs, but also maintaining them long-term.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On the topic of deprecation, we moved the current definition of<br>
deprecation procedures from the soon-to-be-removed tag definition to a<br>
new document in project-team-guide[4]. This now describes the procedures<br>
in terms of the tick-tock release arrangement, and is worth a read.<br></blockquote><div><br></div><div>Same. I don't want to keep deprecated features for a year.<br></div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As the PTG is coming up, we will certainly discuss this topic in the PTL<br>
Interaction[5] session. It would also be advisable to discuss the<br>
project-specific details of this in the various project sessions. By<br>
identifying this plan early and setting our goals for AA, we have a good<br>
amount of time between now and then to get our heads wrapped around what<br>
(if any) things we need to be doing. Luckily, the introduction of the<br>
job to test this from wallaby to yoga required almost no project changes<br>
to get working, which is a good indicator that it won't be too laborious<br>
for most projects to adopt.<br>
<br>
--Dan<br>
<br>
1: <a href="https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html</a><br>
2: <a href="https://review.opendev.org/c/openstack/grenade/+/826101" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/grenade/+/826101</a><br>
3: <a href="https://review.opendev.org/c/openstack/manila/+/830277" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/manila/+/830277</a><br>
4: <a href="https://docs.openstack.org/project-team-guide/deprecation.html" rel="noreferrer" target="_blank">https://docs.openstack.org/project-team-guide/deprecation.html</a><br>
5: <a href="https://etherpad.opendev.org/p/tc-ptl-interaction-zed" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/tc-ptl-interaction-zed</a><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>