<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 23, 2021 at 8:52 AM Marios Andreou <<a href="mailto:marios@redhat.com">marios@redhat.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">On Mon, Jul 19, 2021 at 5:50 PM Marios Andreou <<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a>> wrote:<br>
><br>
> On Tue, Jun 8, 2021 at 6:21 PM Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> wrote:<br>
> ><br>
> > Greetings TripleO community!<br>
> ><br>
> ><br>
> > At the most recent TripleO community meetings we have discussed formally changing the OpenStack release model for TripleO [1].  The previous released projects can be found here [2]. TripleO has previously released with release-type[‘trailing’, ‘cycle-with-intermediary’].<br>
> ><br>
> ><br>
> > To quote the release model doc:<br>
> ><br>
> > ‘Trailing deliverables trail the release, so they cannot, by definition, be independent. They need to pick between cycle-with-rc or cycle-with-intermediary models.’<br>
> ><br>
> ><br>
> > We are proposing to update the release-model to ‘independent’.  This would give the TripleO community more flexibility in when we choose to cut a release.  In turn this would mean less backporting, less upstream and 3rd party resources used by potentially some future releases.<br>
> ><br>
> ><br>
> > To quote the release model doc:<br>
> ><br>
> > ‘Some projects opt to completely bypass the 6-month cycle and release independently. For example, that is the case of projects that support the development infrastructure. The “independent” model describes such projects.’<br>
> ><br>
> ><br>
> > The discussion here is to merely inform the greater community with regards to the proposal and conversations regarding the release model.  This thread is NOT meant to discuss previous releases or their supported status, merely changing the release model here [3]<br>
> ><br>
> ><br>
> ><br>
> > [0] <a href="https://etherpad.opendev.org/p/tripleo-meeting-items" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/tripleo-meeting-items</a><br>
> ><br>
> > [1]  <a href="https://releases.openstack.org/reference/release_models.html" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/release_models.html</a><br>
> ><br>
> > [2] <a href="https://releases.openstack.org/teams/tripleo.html" rel="noreferrer" target="_blank">https://releases.openstack.org/teams/tripleo.html</a><br>
> ><br>
> > [3] <a href="https://opendev.org/openstack/releases/src/branch/master/deliverables/xena" rel="noreferrer" target="_blank">https://opendev.org/openstack/releases/src/branch/master/deliverables/xena</a><br>
> ><br>
> ><br>
><br>
> Hello TripleO and friends o/,<br>
><br>
> It has been over a month since we first introduced this proposal in<br>
> tripleo meetings and weshay started this thread.  Now that we have<br>
> allowed enough time for comments and debate, we’d like to re-focus on<br>
> making a decision.<br>
><br>
> The timing with this change to our release governance is critical to<br>
> stable/xena. One of the main concerns is that CentOS-Stream-9 may not<br>
> be fully available by the xena release.  TripleO would have to carry<br>
> both CentOS-Stream-8 and CentOS-Stream-9 across wallaby and xena and<br>
> master, thus exploding our upstream resource consumption. The<br>
> counterpoint to that is that we are only a few months away from xena<br>
> releasing.<br>
><br>
> As a summary and reminder the three main concerns raised in this<br>
> thread so far were<br>
><br>
> 1. What about compatibility with (rest of) openstack stable branches<br>
> 2. How are feature freeze dates affected (& coordination with other<br>
> projects around feature freeze)<br>
> 3. How does it affect RDO packaging?<br>
><br>
> For  2 and 3 as discussed there will be no implications; RDO has no<br>
> plans to stop packaging for any particular branch so non tripleo<br>
> packages will be built as usual, and, feature freeze (with respect to<br>
> the rest of openstack) doesn’t apply for tripleo since it has always<br>
> been trailing release.<br>
><br>
> For 1 the current proposal is that we will use git tags; a range of<br>
> tags will be designated as compatible with a given stable/release.<br>
> Obviously this needs some more thought and establishing some rules<br>
> (like, bumping major to signal compatibility with a new stable<br>
> branch). To that end we will start a spec (tripleo-specs) to work out<br>
> this and other details and allow folks to comment further.<br>
<br>
spec is posted there<br>
<a href="https://review.opendev.org/c/openstack/tripleo-specs/+/801512" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/tripleo-specs/+/801512</a> please<br>
add your comments<br>
<br>
regards, marios<br>
<br>
<br>
><br>
> This topic will also be raised in the IRC meeting this coming Tuesday<br>
> 20 July [1] so please join us if you are interested in discussing any<br>
> of the points raised here or any new ones that we missed last time,<br>
><br>
> regards, marios<br>
><br>
><br>
> [1]  <a href="http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html</a><br>
<br></blockquote><div><br></div><div><br></div><div>FYI.. TripleO is now under OpenStack's independent release model governance.</div><div><br></div><div>Thanks for everyone's time and input :) </div></div></div>