<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 22, 2017 at 4:32 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Thierry Carrez wrote:<br>
> Now one could argue that the development of OpenStack has slowed down<br>
> enough that a release cycle of 9 months or one year (including only one<br>
> PTG per cycle) would be a better fit.<br>
<br>
</span>Let me expand on that.<br>
<br>
As OpenStack matures, it takes longer for features to land as we are<br>
much more careful about not breaking our existing users. There is less<br>
pressure to get a feature landed in a given release. Time just generally<br>
goes slower, and personally I feel like cycles are getting shorter, with<br>
the next release always just around the corner. Who didn't get the<br>
feeling that the Denver PTG was pretty close to the Atlanta one ?<br>
<br>
As we are working to make OpenStack development more palatable to<br>
part-time contributors, removing a bit of the time pressure might<br>
actually be a good idea too. Development goes slower when you can only<br>
spend 20% of your work time on it.<br>
<br>
Yes, we need to be able to ship early and often, but projects can use<br>
the intermediary releases model to do that. The difference with the<br>
"final" release of a cycle is that we cut a stable branch out of it. We<br>
might not need to maintain a stable branch every 6 months.<br></blockquote><div><br></div><div>Less frequent PTGs? Summits? +1</div><div><br></div></div><br></div></div>