Do we continue to support the previous two releases as stable branches? Doesn't that mean we double the amount of time we need to keep older CI setups around? Isn't that already a pain point for the stable teams?
Michael On Wed, Dec 13, 2017 at 8:17 AM, Thierry Carrez <thie...@openstack.org> 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. > > 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 > - We'd only have one set of community goals per year > - We'd have only one PTG with all teams each year > > 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. > > - 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. > > - 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. > > - 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. > > - 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. > > 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). > > 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 ? > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > 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
