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.kanev...@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:mriede...@gmail.com] > Sent: Wednesday, December 13, 2017 10:52 AM > To: openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
