Open Stack

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.

On Wed, Dec 13, 2017 at 11:13 AM, <Arkady.Kanevsky at dell.com> wrote:

> A lot of great points.
> If we are switching to 1 year cycle do we also move summits/forum to once
> a year...
> That impacts much more than developers.
>
> -----Original Message-----
> From: Matt Riedemann [mailto:mriedemos at gmail.com]
> Sent: Wednesday, December 13, 2017 10:52 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [all] Switching to longer development cycles
>
> On 12/13/2017 10:17 AM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > Over the past year, it has become pretty obvious to me that our
> > self-imposed rhythm no longer matches our natural pace. It feels like
> > we are always running elections, feature freeze is always just around
> > the corner, we lose too much time to events, and generally the
> > impression that there is less time to get things done. Milestones in
> > the development cycles are mostly useless now as they fly past us too
> fast.
> > A lot of other people reported that same feeling.
>
> 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.
>
> >
> > As our various components mature, we have less quick-paced feature
> > development going on. As more and more people adopt OpenStack, we are
> > more careful about not breaking them, which takes additional time. The
> > end result is that getting anything done in OpenStack takes more time
> > than it used to, but we have kept our cycle rhythm mostly the same.
> >
> > Our development pace was also designed for fast development in a time
> > where most contributors were full time on OpenStack. But fewer and
> > fewer people have 100% of their time to dedicate to OpenStack upstream
> > development: a lot of us now have composite jobs or have to
> > participate in multiple communities. This is a good thing, and it will
> > only accelerate as more and more OpenStack development becomes fueled
> > directly by OpenStack operators and users.
> >
> > In another thread, John Dickinson suggested that we move to one-year
> > development cycles, and I've been thinking a lot about it. I now think
> > it is actually the right way to reconcile our self-imposed rhythm with
> > the current pace of development, and I would like us to consider
> > switching to year-long development cycles for coordinated releases as
> > soon as possible.
> >
> > What it means:
> >
> > - We'd only do one *coordinated* release of the OpenStack components
> > per year, and maintain one stable branch per year
> > - We'd elect PTLs for one year instead of every 6 months
>
> If we're running elections too often, we can do this without a change to a
> 1-year dev cycle.
>
> > - We'd only have one set of community goals per year
> > - We'd have only one PTG with all teams each year
>
> 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.
>
> >
> > What it does _not_ mean:
> >
> > - It doesn't mean we'd release components less early or less often.
> > Any project that is in feature development or wants to ship changes
> > more often is encouraged to use the cycle-with-intermediary release
> > model and release very early and very often. It just means that the
> > minimum we'd impose for mature components is one release per year
> > instead of one release every 6 months.
>
> I personally don't expect anyone to pick up these intermediate releases.
> 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.
>
> >
> > - It doesn't mean that we encourage slowing down and procrastination.
> > Each project would be able to set its own pace. We'd actually
> > encourage teams to set objectives for the various (now longer)
> > milestones in the cycle, and organize virtual sprints to get specific
> > objectives done as a group. Slowing down the time will likely let us
> > do a better job at organizing the work that is happening within a cycle.
>
> 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.
>
> >
> > - 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.
>
> 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.
>
> >
> > - It doesn't mean less emphasis on common goals. While we'd set goals
> > only once per year, I hope that having one full year to complete those
> > will let us tackle more ambitious goals, or more of them in parallel.
> >
> > - It doesn't simplify upgrades. The main issue with the pace of
> > upgrading is not the rhythm, it's the imposed timing. Being forced to
> > upgrade every year is only incrementally better than being forced to
> > upgrade every 6 months. The real solution there is better support for
> > skipping releases that don't matter to you, not longer development
> cycles.
>
> Agree that a 1 year dev cycle doesn't make upgrades simpler and fast
> forward upgrades are the answer for people that need to get caught up.
> This also contradicts the assumption that intermediate releases will
> actually be consumed by anyone.
>
> >
> > - 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.
> >
> > Why one year ?
> >
> > Why not switch to 9 months ? Beyond making the math a lot easier, this
> > has mostly to do with events organization. The Summits are already
> > locked for 2018/2019 with a pattern of happening in April/May and
> > October/November. As we want to keep the PTG event as a separate
> > work-focused productive event at the start of every cycle, and not have
> > it collide with one of those already-planned summits, going for a yearly
> > rhythm is the best solution.
>
> If we're being honest, how much of this proposal is driven by the
> Foundation's need to cut back on paying for organized events and people
> in community leadership positions needing to travel less, especially
> when their travel plans have increased with the needs to attend a bunch
> of other non-OpenStack community events?
>
> >
> > When ?
> >
> > If we switch, we could either pick February/March or August/September as
> > the start of cycle / yearly PTG time. From an events organization
> > perspective, it is a lot easier to organize a week-long event in
> > February/March. August is a no-go for a lot of the world. Early
> > September is a mess with various US and religious holidays. Late
> > September is just too close to the October/November summit.
> >
> > So the year-long cycles would ideally start at the beginning of the
> > year, when we would organize the yearly PTG. That said, I'm not sure we
> > can really afford to keep the current rhythm for one more year before
> > switching. That is why I'd like us to consider taking the plunge and
> > just doing it for *Rocky*, and have a single PTG in 2018 (in Dublin).
>
> We can't afford it, literally? Or somehow figuratively, like the current
> imposed pace of development is killing us?
>
> >
> > Who makes the call ?
> >
> > While traditionally the release team has been deciding the exact shape
> > of development cycles, we think that this significant change goes well
> > beyond the release team and needs to be discussed across all of the
> > OpenStack community, with a final decision made by the Technical
> Committee.
> >
> > So... What do you think ?
> >
>
> All in all, like anything, we wouldn't know how this would shake out
> until we tried it and gave enough time to sink it and evaluate. On the
> surface I don't think this really helps with much of anything. As noted,
> a 1 year dev cycle isn't going to get the code written or reviewed any
> faster, but maybe that's not a primary focus. Maybe the primary focus is
> fewer people are focusing on doing OpenStack development and therefore
> we can/should slow down because our developer pool is moving on to other
> shinier things. Elections can be changed without this. Summits that
> aren't in Australia can be changed without this (I would think?).
> Upgrades aren't going to be magically easier as a result, and it would
> arguably make upgrades potentially harder since you'd be consuming a
> year's worth of changes rather than 6 months.
>
> --
>
> Thanks,
>
> Matt
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171213/7866426c/attachment.html>