<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">"<span style="font-family: sans-serif;" class="">I propose that OpenStack only do one release a year instead of two.</span><font face="sans-serif" class="">”</font><div class=""><font face="sans-serif" class=""><br class=""></font></div><div class=""><font face="sans-serif" class="">I am all too happy to chime in and second (or third, or fourth) this notion. It is extremely challenging for many kinds of organizations (government, industry) to keep pace with the two releases per year model. I think it actively harms OpenStack adoption, by creating a sense of instability, or un-maintainability. Big organizations have many dependencies, bureaucracies, privilege separations (often across departments, e.g. systems vs networking vs storage). By the time some orgs get OpenStack running, they’ve already been left in the dust by the pace of the release schedule. Then they run into the security nightmare of maybe not being able to fully patch systems without breaking OpenStack (as Mitaka operators just hit with CentOS 7.4), which scenario forces the constant-upgrade loop pressure (very stressful). An awful lot of negative feelings will be avoided just by having more supportable releases/schedules. Doubtful any of this is a surprise to you all, but it is cathartic for me to say so nonetheless. At any rate, I was not at this Summit and thus missed the session...<br class=""></font><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 5:51 PM, John Dickinson <<a href="mailto:me@not.mn" class="">me@not.mn</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">On 7 Nov 2017, at 15:28, Erik McCormick wrote:</p>
</div>
<div style="white-space:normal" class=""><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><p dir="auto" class="">Hello Ops folks,<br class="">
<br class="">
This morning at the Sydney Summit we had a very well attended and very<br class="">
productive session about how to go about keeping a selection of past<br class="">
releases available and maintained for a longer period of time (LTS).<br class="">
<br class="">
There was agreement in the room that this could be accomplished by<br class="">
moving the responsibility for those releases from the Stable Branch<br class="">
team down to those who are already creating and testing patches for<br class="">
old releases: The distros, deployers, and operators.<br class="">
<br class="">
The concept, in general, is to create a new set of cores from these<br class="">
groups, and use 3rd party CI to validate patches. There are lots of<br class="">
details to be worked out yet, but our amazing UC (User Committee) will<br class="">
be begin working out the details.<br class="">
<br class="">
Please take a look at the Etherpad from the session if you'd like to<br class="">
see the details. More importantly, if you would like to contribute to<br class="">
this effort, please add your name to the list starting on line 133.<br class="">
<br class="">
<a href="https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases" style="color:#777" class="">https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases</a><br class="">
<br class="">
Thanks to everyone who participated!<br class="">
<br class="">
Cheers,<br class="">
Erik<br class="">
<br class="">
_______________________________________________<br class="">
OpenStack-operators mailing list<br class="">
<a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.openstack.org</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" style="color:#777" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a></p>
</blockquote></div>
<div style="white-space:normal" class=""><p dir="auto" class="">I'm not a fan of the current proposal. I feel like the discussion jumped into a policy/procedure solution without getting much more feedback from operators. The room heard "ops want LTS" and we now have a new governance model to work out.</p><p dir="auto" class="">What I heard from ops in the room is that they want (to start) one release a year who's branch isn't deleted after a year. What if that's exactly what we did? I propose that OpenStack only do one release a year instead of two. We still keep N-2 stable releases around. We still do backports to all open stable branches. We still do all the things we're doing now, we just do it once a year instead of twice.</p><p dir="auto" class="">Looking at current deliverables in the openstack releases repo, most (by nearly a factor of 2x) are using "cycle-with-intermediary".</p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px" bgcolor="#F7F7F7" class=""><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7" class="">john@europa:~/Documents/openstack_releases/deliverables/pike(master)$ grep release-model * | cut -d ':' -f 2- | sort | uniq -c
44 release-model: cycle-trailing
147 release-model: cycle-with-intermediary
37 release-model: cycle-with-milestones
2 release-model: untagged
</code></pre><p dir="auto" class="">Any deliverable that using this model is already successfully dealing with skip-level upgrades. Skip-level upgrades are already identified as needed and prioritized functionality in projects that don't yet support them. Let's keep working on getting that functionality supported across all OpenStack deliverables. Let's move to one LTS release a year. And let's get all project deliverables to start using cycle-with-intermediary releases.</p><p dir="auto" class="">--John</p>
</div>
</div>
</div>
_______________________________________________<br class="">OpenStack-operators mailing list<br class=""><a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br class=""></div></blockquote></div><br class=""></div></body></html>