<div dir="ltr">I think we should not mix summits/forum discussion with this and would require a lot more open discussion as has been happening with this proposal prior to it being formally introduced here.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 13, 2017 at 11:13 AM,  <span dir="ltr"><<a href="mailto:Arkady.Kanevsky@dell.com" target="_blank">Arkady.Kanevsky@dell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A lot of great points.<br>
If we are switching to 1 year cycle do we also move summits/forum to once a year...<br>
That impacts much more than developers.<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Matt Riedemann [mailto:<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>]<br>
Sent: Wednesday, December 13, 2017 10:52 AM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
Subject: Re: [openstack-dev] [all] Switching to longer development cycles<br>
<br>
On 12/13/2017 10:17 AM, Thierry Carrez wrote:<br>
> 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<br>
> we are always running elections, feature freeze is always just around<br>
> the corner, we lose too much time to events, and generally the<br>
> impression that there is less time to get things done. Milestones in<br>
> the 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>
On the other hand, without community-wide imposed deadlines and milestones, we lose some motivation for getting things done by a specific time, which could mean the bigger and more complicated things drag on longer because there isn't a deadline. One could say that we just need to be more disciplined, but in an open source project where there is no boss at the top setting that deadline and holding people to it, it's hard to be that disciplined. The PTL can only ask people to work on priorities so much.<br>
<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<br>
> fewer people have 100% of their time to dedicate to OpenStack upstream<br>
> development: a lot of us now have composite jobs or have to<br>
> participate in multiple communities. This is a good thing, and it will<br>
> only 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<br>
> per year, and maintain one stable branch per year<br>
> - We'd elect PTLs for one year instead of every 6 months<br>
<br>
If we're running elections too often, we can do this without a change to a 1-year dev cycle.<br>
<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>
This is arguably going to impact productivity, not improve it - because without the face time to hash out the complicated things, they drag on longer.<br>
<br>
><br>
> What it does _not_ mean:<br>
><br>
> - It doesn't mean we'd release components less early or less often.<br>
> Any project that is in feature development or wants to ship changes<br>
> more often is encouraged to use the cycle-with-intermediary release<br>
> model and release very early and very often. It just means that the<br>
> minimum we'd impose for mature components is one release per year<br>
> instead of one release every 6 months.<br>
<br>
I personally don't expect anyone to pick up these intermediate releases.<br>
I expect most consumers are going to pick up a coordinated release (several months or years after it's released), especially if that's what the distro vendors are going to be doing. So Nova could release once per quarter but I wouldn't expect anyone to pick it up except maybe hosting companies, but not even sure about that.<br>
<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<br>
> encourage teams to set objectives for the various (now longer)<br>
> milestones in the cycle, and organize virtual sprints to get specific<br>
> objectives done as a group. Slowing down the time will likely let us<br>
> do a better job at organizing the work that is happening within a cycle.<br>
<br>
As I said above, encouraging teams to do this and teams actually being disciplined enough to do it are different things. Maybe if we actually did the runways / slots idea from years past but as I've been reminded by people many times over the years, you can't force people to work on someone else's priorities - people are going to scratch their itch.<br>
<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<br>
> meet more often.<br>
<br>
I think the PTG put a nail in the coffin for the self-organized midcycles. I don't expect a lot of companies to be looking to host midcycles at this point, nor send devs to a smaller event like a single team midcycle.<br>
<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>
Agree that a 1 year dev cycle doesn't make upgrades simpler and fast<br>
forward upgrades are the answer for people that need to get caught up.<br>
This also contradicts the assumption that intermediate releases will<br>
actually be consumed by anyone.<br>
<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>
If we're being honest, how much of this proposal is driven by the<br>
Foundation's need to cut back on paying for organized events and people<br>
in community leadership positions needing to travel less, especially<br>
when their travel plans have increased with the needs to attend a bunch<br>
of other non-OpenStack community events?<br>
<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>
We can't afford it, literally? Or somehow figuratively, like the current<br>
imposed pace of development is killing us?<br>
<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>
><br>
<br>
All in all, like anything, we wouldn't know how this would shake out<br>
until we tried it and gave enough time to sink it and evaluate. On the<br>
surface I don't think this really helps with much of anything. As noted,<br>
a 1 year dev cycle isn't going to get the code written or reviewed any<br>
faster, but maybe that's not a primary focus. Maybe the primary focus is<br>
fewer people are focusing on doing OpenStack development and therefore<br>
we can/should slow down because our developer pool is moving on to other<br>
shinier things. Elections can be changed without this. Summits that<br>
aren't in Australia can be changed without this (I would think?).<br>
Upgrades aren't going to be magically easier as a result, and it would<br>
arguably make upgrades potentially harder since you'd be consuming a<br>
year's worth of changes rather than 6 months.<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt<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>
______________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr">Kind regards,<br><br>Melvin Hillsman</div><div dir="ltr"><a href="mailto:mrhillsman@gmail.com" style="color:rgb(17,85,204)" target="_blank">mrhillsman@gmail.com</a><br>mobile: (832) 264-2646<br></div></div></div></div></div></div></div></div></div>
</div>