<div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Dec 13, 2017 at 11: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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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></blockquote><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​</div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Are we convinced that the ~3 day formula​ for the Forum is one we want to stick with ?</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">With longer cycles and no PTGs in-between, it actually sounds like a good opportunity to</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">revisit the "Forum" events to include the "design" and "ops" summits back into the event.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Perhaps not in the previous format, because it had its flaws, but with longer cycles I feel</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">we need something to close that gap.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I've had a lot of discussions and some people that always went to summits now no longer</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">attend neither the PTG (because they don't necessarily contribute upstream) or the Forum</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">because it's only three days, costs a lot of money, jet lag, there's little to no ops/design</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">exposure.. and the talks end up on YouTube anyway.<br></div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">The complaints about the pace of the development and support cycles are numerous and</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I won't repeat them here.</div><br></div></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">While this is not LTS, I can't help but think this is a compromise or a middle ground</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">even though it might not be the intent behind the idea.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Right now we ship a release every 6 months and support each release for 1 year which</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">means at any given time, there are 3 ongoing "releases", including trunk.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">What I'm curious about... is how does this translate into the support cycle ?</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">- Pike was released 2017-08-30 and the scheduled EOL is 2018-09-03.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">- Ocata was released 2017-02-22 and the scheduled EOL is 2018-02-26.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">This can go down a few different ways, I guess we can:</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">1) Extend the support of a stable release by a full year</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    This keeps the two rolling stable releases plus the one in development.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    Not quite LTS, but you know, it's still 2 years of support instead of one.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">2) ​Keep the support cycle to a year</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    This would basically mean that as soon as there is a new release, the</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    previous one would become EOL ? This is what seems suggested here</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    and I'm really not confident this would be a great idea. It would force</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    people to upgrade within weeks after a new release to stay on a supported</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">    version.<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">As some others have mentioned in the thread, there are pros and cons to moving to a</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">year-long cycle and I think it's great that we are having this discussion as it will help</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">us make an informed decision.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">It won't be possible to please everyone so leaving this up to the technical committee</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">to vote on this matter seems fair.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">​David Moreau Simard<br>Senior Software Engineer | OpenStack RDO<br><br>dmsimard = [irc, github, twitter]</div></div></div></div></div>