<div dir="ltr">Do we continue to support the previous two releases as stable branches? Doesn't that mean we double the amount of time we need to keep older CI setups around? Isn't that already a pain point for the stable teams?<div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 13, 2017 at 8:17 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">Hi everyone,<br>
<br>
Over the past year, it has become pretty obvious to me that our<br>
self-imposed rhythm no longer matches our natural pace. It feels like we<br>
are always running elections, feature freeze is always just around the<br>
corner, we lose too much time to events, and generally the impression<br>
that there is less time to get things done. Milestones in the<br>
development cycles are mostly useless now as they fly past us too fast.<br>
A lot of other people reported that same feeling.<br>
<br>
As our various components mature, we have less quick-paced feature<br>
development going on. As more and more people adopt OpenStack, we are<br>
more careful about not breaking them, which takes additional time. The<br>
end result is that getting anything done in OpenStack takes more time<br>
than it used to, but we have kept our cycle rhythm mostly the same.<br>
<br>
Our development pace was also designed for fast development in a time<br>
where most contributors were full time on OpenStack. But fewer and fewer<br>
people have 100% of their time to dedicate to OpenStack upstream<br>
development: a lot of us now have composite jobs or have to participate<br>
in multiple communities. This is a good thing, and it will only<br>
accelerate as more and more OpenStack development becomes fueled<br>
directly by OpenStack operators and users.<br>
<br>
In another thread, John Dickinson suggested that we move to one-year<br>
development cycles, and I've been thinking a lot about it. I now think<br>
it is actually the right way to reconcile our self-imposed rhythm with<br>
the current pace of development, and I would like us to consider<br>
switching to year-long development cycles for coordinated releases as<br>
soon as possible.<br>
<br>
What it means:<br>
<br>
- We'd only do one *coordinated* release of the OpenStack components per<br>
year, and maintain one stable branch per year<br>
- We'd elect PTLs for one year instead of every 6 months<br>
- We'd only have one set of community goals per year<br>
- We'd have only one PTG with all teams each year<br>
<br>
What it does _not_ mean:<br>
<br>
- It doesn't mean we'd release components less early or less often. Any<br>
project that is in feature development or wants to ship changes more<br>
often is encouraged to use the cycle-with-intermediary release model and<br>
release very early and very often. It just means that the minimum we'd<br>
impose for mature components is one release per year instead of one<br>
release every 6 months.<br>
<br>
- It doesn't mean that we encourage slowing down and procrastination.<br>
Each project would be able to set its own pace. We'd actually encourage<br>
teams to set objectives for the various (now longer) milestones in the<br>
cycle, and organize virtual sprints to get specific objectives done as a<br>
group. Slowing down the time will likely let us do a better job at<br>
organizing the work that is happening within a cycle.<br>
<br>
- It doesn't mean that teams can only meet in-person once a year.<br>
Summits would still provide a venue for team members to have an<br>
in-person meeting. I also expect a revival of the team-organized<br>
midcycles to replace the second PTG for teams that need or want to meet<br>
more often.<br>
<br>
- It doesn't mean less emphasis on common goals. While we'd set goals<br>
only once per year, I hope that having one full year to complete those<br>
will let us tackle more ambitious goals, or more of them in parallel.<br>
<br>
- It doesn't simplify upgrades. The main issue with the pace of<br>
upgrading is not the rhythm, it's the imposed timing. Being forced to<br>
upgrade every year is only incrementally better than being forced to<br>
upgrade every 6 months. The real solution there is better support for<br>
skipping releases that don't matter to you, not longer development cycles.<br>
<br>
- It doesn't give us LTS. The cost of maintaining branches is not really<br>
due to the number of them we need to maintain in parallel, it is due to<br>
the age of the oldest one. We might end up being able to support<br>
branches for slightly longer as a result of having to maintain less of<br>
them in parallel, but we will not support our stable branches for a<br>
significantly longer time as a direct result of this change. The real<br>
solution here is being discussed by the (still forming) LTS SIG and<br>
involves having a group step up to continue to maintain some branches<br>
past EOL.<br>
<br>
Why one year ?<br>
<br>
Why not switch to 9 months ? Beyond making the math a lot easier, this<br>
has mostly to do with events organization. The Summits are already<br>
locked for 2018/2019 with a pattern of happening in April/May and<br>
October/November. As we want to keep the PTG event as a separate<br>
work-focused productive event at the start of every cycle, and not have<br>
it collide with one of those already-planned summits, going for a yearly<br>
rhythm is the best solution.<br>
<br>
When ?<br>
<br>
If we switch, we could either pick February/March or August/September as<br>
the start of cycle / yearly PTG time. From an events organization<br>
perspective, it is a lot easier to organize a week-long event in<br>
February/March. August is a no-go for a lot of the world. Early<br>
September is a mess with various US and religious holidays. Late<br>
September is just too close to the October/November summit.<br>
<br>
So the year-long cycles would ideally start at the beginning of the<br>
year, when we would organize the yearly PTG. That said, I'm not sure we<br>
can really afford to keep the current rhythm for one more year before<br>
switching. That is why I'd like us to consider taking the plunge and<br>
just doing it for *Rocky*, and have a single PTG in 2018 (in Dublin).<br>
<br>
Who makes the call ?<br>
<br>
While traditionally the release team has been deciding the exact shape<br>
of development cycles, we think that this significant change goes well<br>
beyond the release team and needs to be discussed across all of the<br>
OpenStack community, with a final decision made by the Technical Committee.<br>
<br>
So... What do you think ?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</font></span></blockquote></div><br></div>