Open Stack

On Wed, Dec 13, 2017 at 11:17 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> - It doesn't mean that teams can only meet in-person once a year.
> Summits would still provide a venue for team members to have an
> in-person meeting. I also expect a revival of the team-organized
> midcycles to replace the second PTG for teams that need or want to meet
> more often.
>
​
Are we convinced that the ~3 day formula​ for the Forum is one we want to
stick with ?
With longer cycles and no PTGs in-between, it actually sounds like a good
opportunity to
revisit the "Forum" events to include the "design" and "ops" summits back
into the event.

Perhaps not in the previous format, because it had its flaws, but with
longer cycles I feel
we need something to close that gap.

I've had a lot of discussions and some people that always went to summits
now no longer
attend neither the PTG (because they don't necessarily contribute upstream)
or the Forum
because it's only three days, costs a lot of money, jet lag, there's little
to no ops/design
exposure.. and the talks end up on YouTube anyway.


> - It doesn't give us LTS. The cost of maintaining branches is not really
> due to the number of them we need to maintain in parallel, it is due to
> the age of the oldest one. We might end up being able to support
> branches for slightly longer as a result of having to maintain less of
> them in parallel, but we will not support our stable branches for a
> significantly longer time as a direct result of this change. The real
> solution here is being discussed by the (still forming) LTS SIG and
> involves having a group step up to continue to maintain some branches
> past EOL.
>


The complaints about the pace of the development and support cycles are
numerous and
I won't repeat them here.

While this is not LTS, I can't help but think this is a compromise or a
middle ground
even though it might not be the intent behind the idea.
Right now we ship a release every 6 months and support each release for 1
year which
means at any given time, there are 3 ongoing "releases", including trunk.

What I'm curious about... is how does this translate into the support cycle
?

- Pike was released 2017-08-30 and the scheduled EOL is 2018-09-03.
- Ocata was released 2017-02-22 and the scheduled EOL is 2018-02-26.

This can go down a few different ways, I guess we can:
1) Extend the support of a stable release by a full year
    This keeps the two rolling stable releases plus the one in development.
    Not quite LTS, but you know, it's still 2 years of support instead of
one.

2) ​Keep the support cycle to a year
    This would basically mean that as soon as there is a new release, the
    previous one would become EOL ? This is what seems suggested here
    and I'm really not confident this would be a great idea. It would force
    people to upgrade within weeks after a new release to stay on a
supported
    version.

As some others have mentioned in the thread, there are pros and cons to
moving to a
year-long cycle and I think it's great that we are having this discussion
as it will help
us make an informed decision.

It won't be possible to please everyone so leaving this up to the technical
committee
to vote on this matter seems fair.

​David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171213/5d1e3422/attachment.html>